Tốc độ tuần tự chậm trên raidz2 ổ 9x7 (ZFS ZoL 0.8.1)


9

Tôi đang chạy một nhóm ZFS lớn được xây dựng để đọc và ghi tuần tự kích thước yêu cầu 256K + qua iSCSI (để sao lưu) trên Ubuntu 18.04. Do nhu cầu về thông lượng cao và hiệu quả không gian, và ít cần hiệu suất khối nhỏ ngẫu nhiên, tôi đã sử dụng raidz2 sọc trên gương sọc.

Tuy nhiên, hiệu suất đọc tuần tự 256K thấp hơn nhiều so với tôi mong đợi (100 - 200MBps, đỉnh lên tới 600MBps). Khi các zvols đạt ~ 99% iowait trong iuler, các thiết bị sao lưu thường chạy từ 10 đến 40% iowait, điều này cho tôi thấy nút cổ chai là thứ tôi thiếu trong cấu hình, vì nó không phải là bảng nối đa năng hoặc CPU trong hệ thống này và khối lượng công việc tuần tự không nên làm việc quá nặng.

Tôi đã chơi khá nhiều với các tham số mô-đun (cấu hình hiện tại bên dưới), đọc hàng trăm bài viết, các vấn đề trên github OpenZFS, v.v. Điều chỉnh tìm nạp trước và tổng hợp đã đưa tôi đến mức hiệu suất này - theo mặc định, tôi đang chạy với tốc độ khoảng ~ 50MBps đọc tuần tự khi ZFS đang gửi yêu cầu TINY đến các đĩa (~ 16K). Với tính năng tổng hợp và tìm nạp trước hoạt động tốt (tôi nghĩ), số lần đọc đĩa cao hơn nhiều, trung bình khoảng ~ 64K trong i điều chỉnh.

Các NIC là mục tiêu iscsi LIO với giảm tải cxgbit + Bộ khởi tạo iscsi Windows Chelsio hoạt động tốt bên ngoài các zvols ZFS, với một optane được ánh xạ trực tiếp trả về tốc độ dòng gần như đầy đủ trên các NIC (~ 3,5 GBps đọc và ghi).

Tôi đang mong đợi quá nhiều? Tôi biết ZFS ưu tiên an toàn hơn hiệu năng, nhưng tôi mong đợi một raidz2 7x9 sẽ cung cấp khả năng đọc tuần tự tốt hơn so với một mdadm raid6 9 ổ đĩa đơn.

Thông số hệ thống và tệp nhật ký / cấu hình:

Chassis: Supermicro 6047R-E1R72L
HBAs: 3x 2308 IT mode (24x 6Gbps SAS channels to backplanes)
CPU: 2x E5-2667v2 (8 cores @ 3.3Ghz base each)
RAM: 128GB, 104GB dedicated to ARC
HDDs: 65x HGST 10TB HC510 SAS (9x 7-wide raidz2 + 2 spares)
SSDs: 2x Intel Optane 900P (partitioned for mirrored special and log vdevs)
NIC: Chelsio 40GBps (same as on initiator, both using hw offloaded iSCSI)
OS: Ubuntu 18.04 LTS (using latest non-HWE kernel that allows ZFS SIMD)
ZFS: 0.8.1 via PPA
Initiator: Chelsio iSCSI initiator on Windows Server 2019

Cấu hình bể bơi:

ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all

Cấu hình ZVol:

sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)

Bố trí bể bơi:

7x 9-wide raidz2
mirrored 200GB optane special vdev (SPA metadata allocation classes)
mirrored 50GB optane log vdev

/etc/modprobe.d/zfs.conf:

# 52 - 104GB ARC, this system does nothing else
options zfs zfs_arc_min=55834574848
options zfs zfs_arc_max=111669149696

# allow for more dirty async data
options zfs zfs_dirty_data_max_percent=25
options zfs zfs_dirty_data_max=34359738368

# txg timeout given we have plenty of Optane ZIL
options zfs zfs_txg_timeout=5

# tune prefetch (have played with this 1000x different ways, no major improvement except max_streams to 2048, which helped, I think)
options zfs zfs_prefetch_disable=0
options zfs zfetch_max_distance=134217728
options zfs zfetch_max_streams=2048
options zfs zfetch_min_sec_reap=3
options zfs zfs_arc_min_prefetch_ms=250
options zfs zfs_arc_min_prescient_prefetch_ms=250
options zfs zfetch_array_rd_sz=16777216

# tune coalescing (same-ish, increasing the read gap limit helped throughput in conjunction with low async read max_active, as it caused much bigger reads to be sent to the backing devices)
options zfs zfs_vdev_aggregation_limit=16777216
options zfs zfs_vdev_read_gap_limit=1048576
options zfs zfs_vdev_write_gap_limit=262144

# ZIO scheduler in priority order 
options zfs zfs_vdev_sync_read_min_active=1
options zfs zfs_vdev_sync_read_max_active=10
options zfs zfs_vdev_sync_write_min_active=1
options zfs zfs_vdev_sync_write_max_active=10
options zfs zfs_vdev_async_read_min_active=1
options zfs zfs_vdev_async_read_max_active=2
options zfs zfs_vdev_async_write_min_active=1
options zfs zfs_vdev_async_write_max_active=4

# zvol threads
options zfs zvol_threads=32

Tôi đang xé tóc vì điều này. Áp lực từ người dùng đi tất cả Windows với Storage Spaces, nhưng tôi đã sử dụng không gian lưu trữ chẵn lẻ (ngay cả với Storage Spaces Direct có gương ở trên cùng), và nó cũng không đẹp. Tôi muốn đi thẳng mdadm raid60 theo iSCSI, nhưng tôi rất thích nếu ai đó có thể chỉ ra thứ gì đó xương tôi đang thiếu sẽ mở khóa hiệu năng với bảo vệ bitrot của ZFS :)

Câu trả lời:


7

Câu hỏi hay.

  • Tôi nghĩ kích thước khối zvol thưa thớt của bạn nên là 128k.
  • Tất cả các cài đặt lịch trình ZIO của bạn phải cao hơn, như tối thiểu 10 và tối đa 64.
  • zfs_txg_timeout sẽ dài hơn nhiều. Tôi làm 15 hoặc 30 giây trên hệ thống của mình.
  • Tôi nghĩ rằng nhiều RAIDZ3 (hoặc là một lỗi đánh máy) là quá mức cần thiết và đóng một vai trò lớn trong hiệu suất. Bạn có thể điểm chuẩn với RAIDZ2 không?

Chỉnh sửa: Cài đặt Netdata trên hệ thống và theo dõi việc sử dụng và thống kê ZFS.

Edit2: Đây là một kho lưu trữ Veeam. Veeam hỗ trợ Linux làm mục tiêu và hoạt động tuyệt vời với ZFS. Bạn sẽ xem xét điểm chuẩn với dữ liệu của bạn? zvols không phải là trường hợp sử dụng lý tưởng cho những gì bạn đang làm, trừ khi giảm tải của NIC là một phần quan trọng của giải pháp.


Cảm ơn! Từng điểm trong các bình luận tiếp theo, ngoại trừ Z3 thực sự là một lỗi đánh máy :). Trên volblocksize, tôi đã thử nghiệm với cả 128k và 64k và hiệu suất không thay đổi nhiều cho các lần đọc liên tiếp. 128k có thể sẽ tiết kiệm không gian hơn một chút, nhưng 64k phù hợp với kích thước đơn vị phân bổ hệ điều hành máy khách khởi tạo và dường như làm tốt hơn đáng kể trong các trường hợp i / o ngẫu nhiên (rất hiếm), trong khi không quan trọng lắm trong các kịch bản i / o tuần tự .
obrienmd

Tôi sẽ kiểm tra với txg_timeout cao hơn - điều đó có quan trọng trong việc đọc tuần tự không? Với iowait thấp trên các đĩa sao lưu, có vẻ như các luồng ghi có liên quan đến / ảnh hưởng đến tốc độ đọc trung bình nhiều.
obrienmd

1
Phản hồi thú vị nhất tôi dành cho bạn (tôi nghĩ) là dành cho người lập lịch ZIO. Khi tôi di chuyển kim vào phút và tối đa không đồng bộ, nó sẽ phá hủy tập hợp io và kết quả thực là khá tệ. Đối với việc đọc, đó là điều tôi thực sự quan tâm ở đây vì việc ghi rất tuyệt vời, đến ngày 10/64 sẽ tạo ra IO trung bình cho các đĩa ~ 16KB trong iuler và giảm tốc độ đọc trung bình 75% (~ 30 - 60MBps) cho các đĩa đó 'IOPS. Tôi cũng đã điều chỉnh đồng bộ hóa đọc #s và không thấy nhiều ảnh hưởng, nhưng tôi sẽ cho một lần chụp khác bất kể :)
obrienmd

zfs zfs_denty_data_max_percent = 25 - Tôi thường 40% hoặc cao hơn ở đó.
ewwhite

Oh, đọc là một vấn đề? Đây là loại dữ liệu gì? Làm thế nào đầy đủ là hồ bơi?
ewwhite
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.