Hiệu suất ZFS: tôi có cần giữ không gian trống trong nhóm hoặc hệ thống tệp không?

Tôi biết rằng hiệu suất của ZFS phụ thuộc nhiều vào dung lượng trống:

Giữ không gian hồ bơi dưới mức sử dụng 80% để duy trì hiệu suất hồ bơi. Hiện tại, hiệu suất nhóm có thể giảm khi nhóm rất đầy đủ và hệ thống tệp được cập nhật thường xuyên, chẳng hạn như trên máy chủ thư bận. Nhóm đầy đủ có thể gây ra một hình phạt hiệu suất, nhưng không có vấn đề khác. [...] Hãy nhớ rằng ngay cả với nội dung chủ yếu là tĩnh trong phạm vi 95-96%, hiệu suất viết, đọc và khả năng phục hồi có thể bị ảnh hưởng. ZFS_Best_Practices_Guide, solarisi INTERNals.com (archive.org)

Bây giờ, giả sử tôi có một nhóm raidz2 gồm 10T lưu trữ hệ thống tệp ZFS volume. Bây giờ tôi tạo một hệ thống tệp con volume/testvà đặt trước 5T.

Sau đó, tôi gắn cả hai hệ thống tệp trên mỗi NFS vào một số máy chủ lưu trữ và thực hiện một số công việc. Tôi hiểu rằng tôi không thể viết thư cho volumehơn 5T, vì 5T còn lại được dành riêng cho volume/test.

Câu hỏi đầu tiên của tôi là, hiệu suất sẽ giảm như thế nào, nếu tôi lấp đầy volumeđiểm gắn kết của mình với ~ 5T? Nó sẽ bị hủy, bởi vì không có không gian trống trong hệ thống tệp đó cho bản sao chép khi ghi và các công cụ meta khác của ZFS? Hoặc nó sẽ giữ nguyên, vì ZFS có thể sử dụng không gian trống trong không gian dành riêng cho volume/test?

Bây giờ là câu hỏi thứ hai . Liệu nó có làm nên sự khác biệt, nếu tôi thay đổi thiết lập như sau? volumebây giờ có hai hệ thống tập tin, volume/test1và volume/test2. Cả hai đều được đặt trước 3T mỗi lần (nhưng không có hạn ngạch). Giả sử bây giờ, tôi viết 7T đến test1. Hiệu suất của cả hai hệ thống tệp sẽ giống nhau hay sẽ khác nhau đối với mọi hệ thống tệp? Nó sẽ giảm, hoặc giữ nguyên?

Cảm ơn!

Đúng. Bạn cần giữ không gian trống trong hồ bơi của bạn. Nó chủ yếu dành cho các hành động sao chép và ghi ảnh. Hiệu suất giảm ở mức sử dụng khoảng 85%. Bạn có thể lên cao hơn, nhưng có một tác động nhất định.

Đừng lộn xộn với các đặt phòng. Đặc biệt là với NFS. Nó không cần thiết. Có thể cho một zvol, nhưng không phải NFS.

Tôi không thấy sự nhầm lẫn, mặc dù. Nếu bạn có 10T, đừng sử dụng hơn 85%. Kích thước cổ phiếu của bạn một cách thích hợp, sử dụng hạn ngạch để giới hạn việc sử dụng chúng. Hoặc không sử dụng bất kỳ hạn ngạch và theo dõi việc sử dụng hồ bơi tổng thể của bạn .

Sự suy giảm hiệu suất xảy ra khi zpool của bạn rất đầy đủ hoặc rất phân mảnh. Lý do cho điều này là cơ chế phát hiện khối miễn phí được sử dụng với ZFS. Đối lập với các hệ thống tệp khác như NTFS hoặc ext3, không có bitmap khối nào hiển thị khối nào bị chiếm dụng và khối nào là miễn phí. Thay vào đó, ZFS chia zvol của bạn thành (thường là 200) khu vực lớn hơn gọi là "metaslabs" và lưu trữ AVL-cây ¹ thông tin khối miễn phí (bản đồ không gian) trong mỗi metaslab. Cây AVL cân bằng cho phép tìm kiếm hiệu quả cho một khối phù hợp với kích thước của yêu cầu.

Mặc dù cơ chế này đã được chọn vì lý do quy mô, nhưng thật không may, nó cũng trở thành một nỗi đau lớn khi mức độ phân mảnh và / hoặc sử dụng không gian cao xảy ra. Ngay khi tất cả các metaslab mang một lượng dữ liệu đáng kể, bạn sẽ nhận được một số lượng lớn các khu vực nhỏ của các khối miễn phí, trái ngược với một số lượng nhỏ các khu vực lớn khi hồ bơi trống rỗng. Nếu ZFS sau đó cần phân bổ 2 MB dung lượng, nó bắt đầu đọc và đánh giá tất cả các bản đồ không gian của metaslabs để tìm một khối phù hợp hoặc cách chia 2 MB thành các khối nhỏ hơn. Điều này tất nhiên mất một thời gian. Điều tồi tệ hơn là thực tế là nó sẽ tốn rất nhiều thao tác I / O vì ZFS thực sự sẽ đọc tất cả các bản đồ không gian khỏi các đĩa vật lý . Đối với bất kỳ bài viết của bạn.

Hiệu suất giảm có thể là đáng kể. Nếu bạn thích những bức ảnh đẹp, hãy xem bài đăng trên blog tại Delphix , trong đó có một số con số được lấy ra từ một nhóm zfs (quá cỡ nhưng vẫn hợp lệ). Tôi xấu hổ ăn cắp một trong các biểu đồ - nhìn vào các đường màu xanh lam, đỏ, vàng và xanh lục trong biểu đồ này (tương ứng) đại diện cho các nhóm ở mức 10%, 50%, 75% và 93% công suất được vẽ chống lại thông lượng ghi trong KB / s trong khi bị phân mảnh theo thời gian:

Cách khắc phục nhanh và bẩn cho điều này theo truyền thống là chế độ gỡ lỗi metaslab (chỉ phát hành echo metaslab_debug/W1 | mdb -kwvào thời gian chạy để thay đổi cài đặt ngay lập tức). Trong trường hợp này, tất cả các bản đồ không gian sẽ được giữ trong RAM hệ điều hành, loại bỏ yêu cầu về I / O quá mức và tốn kém trên mỗi thao tác ghi. Cuối cùng, điều này cũng có nghĩa là bạn cần nhiều bộ nhớ hơn, đặc biệt là đối với các hồ bơi lớn, vì vậy đây là loại RAM để lưu trữ giao dịch ngựa. Nhóm 10 TB của bạn có thể sẽ tiêu tốn 2-4 GB bộ nhớ ² , nhưng bạn sẽ có thể điều khiển nó tới 95% mức sử dụng mà không gặp nhiều rắc rối.

¹ thì phức tạp hơn một chút, nếu bạn quan tâm, hãy xem bài đăng của Bonwick trên bản đồ không gian để biết chi tiết

² nếu bạn cần một cách để tính giới hạn trên cho bộ nhớ, hãy sử dụng zdb -mm <pool>để lấy số lượng segmentshiện đang sử dụng trong mỗi metaslab, chia cho hai để mô hình một trường hợp xấu nhất (mỗi phân đoạn bị chiếm dụng sẽ được theo sau bởi một phân đoạn miễn phí ), nhân nó với kích thước bản ghi cho một nút AVL (hai con trỏ bộ nhớ và một giá trị, với bản chất 128 bit của zfs và địa chỉ 64 bit sẽ tổng hợp lên đến 32 byte, mặc dù mọi người dường như thường giả sử 64 byte cho một số lý do).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

Tham khảo: phác thảo cơ bản có trong bài đăng này của Markus Kovero trong danh sách gửi thư thảo luận zfs , mặc dù tôi tin rằng anh ta đã phạm một số sai lầm trong tính toán mà tôi hy vọng đã sửa chữa trong tôi.