Tôi biết rằng không có điểm nào (thực tế đó là một ý tưởng tồi) để chạy Defrag trên SSD. Thế còn một máy ảo chạy trên SSD, tôi có nên chống phân mảnh ổ cứng của nó không vì nó cơ bản truy cập vào Ổ cứng theo cách tương tự?
Tôi biết rằng không có điểm nào (thực tế đó là một ý tưởng tồi) để chạy Defrag trên SSD. Thế còn một máy ảo chạy trên SSD, tôi có nên chống phân mảnh ổ cứng của nó không vì nó cơ bản truy cập vào Ổ cứng theo cách tương tự?
Câu trả lời:
Tôi chống phân mảnh VHD của mình nhưng vì lý do không gian, không phải thời gian:
Tôi sử dụng tùy chọn phân bổ động cho VHD, để chúng bắt đầu nhỏ và mở rộng khi cần. Nhưng khi VHD (không nhất thiết là các tệp) bị phân mảnh, nó sẽ mở rộng để bao gồm tất cả các khối được phân bổ. Chống phân mảnh VHD là bước đầu tiên để nén lại.
Không cần phải chống phân mảnh ổ SSD. Một ổ cứng thông thường phải quay để tìm (các phần của) tệp. Một ổ SSD tương đương với RAM, tất cả các tệp có thể đạt được với cùng độ trễ.
Wikipedia nói rằng "Hiệu suất đọc không thay đổi dựa trên nơi dữ liệu được lưu trữ trên ổ SSD"
Đây chỉ là ý kiến của tôi, tôi không có kết quả kiểm tra để sao lưu. Đây là một xấp xỉ sơ bộ về cách mọi thứ có thể xảy ra:
Hệ điều hành thực sự:
Đây sẽ là chuỗi lệnh tương đương trong VM:
Như bạn có thể thấy, trong cả hai trường hợp, sự phân mảnh chỉ thực sự trở thành một vấn đề ở giai đoạn hoạt động khi ổ cứng vật lý cố đọc dữ liệu và điều đó xảy ra trong HĐH thực, bên ngoài bối cảnh VM. Trước đó, mọi thứ có thể xảy ra trong bộ nhớ.
Tóm lại, vì chúng ta biết rằng SSD không bị phân mảnh trong HĐH thực và vấn đề phân mảnh trong máy ảo có lẽ chỉ xảy ra ở bước vật lý cuối cùng của hoạt động, tôi đoán rằng việc chống phân mảnh hệ điều hành ảo của bạn hoặc tệp đĩa ảo trong HĐH chính của bạn sẽ không cải thiện hiệu suất trên SSD, trong khi gây bất lợi / vô dụng như chống phân mảnh hệ điều hành thực của bạn.
Chỉnh sửa: Và nếu đó là chính xác, đó là một lý do chính đáng để đặt VM trên SSD! Trên ổ cứng, phân mảnh ở bất kỳ giai đoạn nào (hệ điều hành khách, tệp đĩa ảo, hệ điều hành thực) sẽ phá vỡ tuyến tính và gây ra sự phân mảnh ở bước đĩa vật lý.
Cho dù Máy ảo của bạn đang truy cập dữ liệu được lưu trữ trên ổ cứng từ tính truyền thống hoặc SSD điện tử, tệp NTFS của Windows & phân mảnh không gian trống sẽ làm chậm tốc độ truy cập của các ứng dụng yêu cầu dữ liệu. Tệp NTFS và phân mảnh không gian trống xảy ra thường xuyên hơn nhiều so với bạn có thể đoán. Nó có khả năng xảy ra ngay khi bạn cài đặt hệ điều hành. Nó có thể xảy ra khi bạn cài đặt các ứng dụng hoặc cập nhật hệ thống, truy cập internet, tải xuống và lưu ảnh, tạo e-mail, tài liệu văn phòng, v.v. tất cả các ứng dụng và hiệu suất hệ thống. Khi sự phân mảnh xảy ra, hệ thống máy tính và bộ lưu trữ cơ bản đang thực hiện nhiều công việc hơn mức cần thiết. Mỗi yêu cầu I / O cần một lượng thời gian có thể đo được. Ngay cả trong môi trường SSD cũng không có yêu cầu I / O ngay lập tức. Bất cứ khi nào một ứng dụng yêu cầu đọc hoặc ghi dữ liệu và yêu cầu đó được chia thành các yêu cầu I / O bổ sung, nó sẽ khiến nhiều việc phải được thực hiện. Công việc làm thêm này gây ra sự chậm trễ ngay tại thời điểm đó.
Ổ đĩa đã nhanh hơn trong những năm qua, nhưng CPU cũng vậy. Trong thực tế, khoảng cách giữa sự khác biệt về tốc độ giữa đĩa cứng và CPU đã thực sự mở rộng. Điều này có nghĩa là các ứng dụng có thể nhận được nhiều chu kỳ CPU, nhưng chúng vẫn đang đói để lấy dữ liệu từ bộ lưu trữ. Hơn nữa, lượng dữ liệu đang được lưu trữ đã tăng lên đáng kể. Chỉ cần nghĩ về tất cả những bức ảnh kỹ thuật số được chụp và chia sẻ trong những ngày lễ. Mỗi ảnh sử dụng có kích thước xấp xỉ 1 MB, hiện tại chúng vượt quá 15 MB cho mỗi ảnh và một số khác vượt xa. Chỉnh sửa video và kết xuất và lưu trữ phim kỹ thuật số cũng trở nên khá phổ biến và kết quả là các ứng dụng đang thao túng hàng trăm Gigabyte dữ liệu. Với kích thước cụm đĩa điển hình là 4k, tệp kích thước 15 MB có khả năng bị phân mảnh thành gần 4.000 phạm vi. Điều này có nghĩa là thêm 4, Yêu cầu 000 đĩa I / O để đọc hoặc ghi tệp. Bất kể loại lưu trữ nào, đơn giản là sẽ mất nhiều thời gian hơn để hoàn thành thao tác.
Vị trí vật lý của dữ liệu trên ổ SSD không thực sự quan trọng như trên ổ cứng từ tính thông thường. Với ổ SSD, không có độ trễ quay hoặc tìm thời gian để tranh chấp. Nhiều chuyên gia cho rằng sự phân mảnh không còn là vấn đề nữa, nhưng tốc độ truy cập dữ liệu ứng dụng không chỉ được định nghĩa trong các điều khoản đó. Mỗi và mọi yêu cầu I / O được thực hiện đều cần một lượng thời gian có thể đo được. SSD là nhanh, nhưng chúng không phải là ngay lập tức. Hệ thống tệp NTFS của Windows không hoạt động khác đi vì bộ nhớ bên dưới là SSD so với HDD và do đó vẫn xảy ra sự phân mảnh. Giảm các I / O không cần thiết bằng cách ngăn chặn và xóa bỏ phân mảnh làm giảm số lượng yêu cầu I / O và kết quả là tăng tốc thời gian đáp ứng dữ liệu của ứng dụng và cải thiện tuổi thọ chung của SSD. Về bản chất,
Ngoài ra, SSD yêu cầu xóa dữ liệu cũ trước khi dữ liệu mới được ghi trên đó, thay vì chỉ ghi thông tin cũ như với ổ cứng. Điều này làm tăng gấp đôi hao mòn và có thể gây ra vấn đề lớn với hiệu suất tốc độ và tuổi thọ của SSD. Hầu hết các nhà sản xuất SSD đều có các công nghệ cân bằng hao mòn rất tinh vi để hỗ trợ việc này. Vấn đề nguyên tắc là suy giảm tốc độ ghi do sự phân mảnh không gian trống. Các không gian trống nhỏ nằm rải rác trên SSD khiến hệ thống tệp NTFS ghi một tệp thành các mảnh bị phân mảnh vào các không gian trống nhỏ có sẵn đó. Điều này có tác dụng gây ra lưu lượng truy cập I / O ngẫu nhiên chậm hơn so với các hoạt động tuần tự.
Tôi có kết quả điểm chuẩn để sao lưu này. Nếu bạn muốn, hãy viết bình luận, yêu cầu những kết quả này và tôi rất vui được chia sẻ chúng với bạn.
Liên quan đến câu hỏi ban đầu về phân mảnh truyền thống của SSD, tôi đồng ý rằng đó là một ý tưởng tồi, nhưng có những giải pháp cụ thể có sẵn để giải quyết các mối quan tâm về chuyển động của tệp và tuổi thọ của SSD.
Một máy ảo đang chạy Windows như hệ điều hành của nó, sự phân mảnh vẫn sẽ xảy ra và hiệu ứng kết hợp của lưu lượng I / O bổ sung sẽ làm giảm tốc độ và hiệu quả của không chỉ các hệ thống khách mà cả của máy chủ. Cả Microsoft và VMware đều khuyến nghị cần giải quyết sự phân mảnh ở cấp độ khách.
Đây là lý do tại sao…
Ứng dụng yêu cầu dữ liệu X
Yêu cầu được xử lý bởi NTFS.sys
Các thuộc tính tệp được kiểm tra ($ MFT) và nếu dữ liệu không được chứa trong một phạm vi (đoạn) thì các yêu cầu I / O bổ sung được tạo cho từng phạm vi / đoạn để đáp ứng yêu cầu dữ liệu gốc.
Mỗi yêu cầu này sau đó được gửi đến trình điều khiển lưu trữ đĩa.
Khi dữ liệu được truy xuất, nó sẽ được gửi lại ngăn xếp cho người dùng / ứng dụng.
Mỗi máy ảo Windows đang gửi loại lưu lượng I / O này đến hệ thống Máy chủ. Nếu cấu trúc hệ thống tệp bị phân mảnh ở cấp độ máy khách / ảo thì điều này chuyển thành lưu lượng truy cập I / O bổ sung và không cần thiết phải được xử lý bởi Máy chủ lưu trữ và lưu trữ bộ lưu trữ phụ trợ. Điều này càng thêm phức tạp khi bạn thêm ngày càng nhiều máy ảo. Trong thực tế, bạn có thể có phân mảnh trong phân mảnh ở cấp hệ thống tệp máy chủ.
Cho dù dữ liệu được lưu trữ trên ổ SSD hay ổ cứng truyền thống, nếu bạn đang chạy Windows, hệ thống tệp NTFS sẽ bị phân mảnh và kết quả là bạn sẽ không bao giờ đạt được tốc độ và thông lượng định mức của nhà sản xuất do tệp NTFS và phân mảnh không gian trống. Các hiệu ứng có thể được đo thông qua PerfMon bằng cách xem Độ dài hàng đợi đọc trung bình trên đĩa, Độ dài hàng đợi ghi trung bình và quan trọng nhất là Chia IO / giây.
Bắt đầu với Windows Server 2008 và Windows Vista, hãy cẩn thận với tác vụ chống phân mảnh theo lịch trình mặc định của Windows.
Nó có thể bị vô hiệu hóa với: schtasks /change / tn “microsoft\windows\defrag\ScheduledDefrag” /disable
hoặc sử dụng PowerShell:
Get-ScheduledTask ScheduledDefrag | Disable-ScheduledTask
Trích xuất từ: http://www.sysadmit.com/2015/10/vmware-y-gpo-defrag-windows.html
Tôi vừa mới phân mảnh máy ảo VMLite XPMode bằng cách sử dụng phân mảnh windows được lưu trữ trên 240Gb INTEL SSDSC2CW240A3.
Kích thước trước phân mảnh VM trên máy chủ - 7.83Gb (Dung lượng được sử dụng trên C: trên VM, 5,81Gb là 121Gb)
Chống phân mảnh bài đăng - 9,86Gb (Không gian được sử dụng trên C: trên VM, 5,80Gb của 121Gb)
Không phải là kết quả mà tôi mong đợi và tôi đã khôi phục phiên bản chống phân mảnh.