Kecepatan berurutan lambat pada raidz2 9x7-drive (ZFS ZoL 0.8.1)

Saya menjalankan kumpulan ZFS besar yang dibangun untuk 256K + permintaan ukuran sekuensial membaca dan menulis melalui iSCSI (untuk cadangan) di Ubuntu 18.04. Mengingat kebutuhan untuk throughput tinggi dan efisiensi ruang, dan sedikit kebutuhan untuk kinerja blok kecil acak, saya pergi dengan raidz2 bergaris di atas cermin bergaris.

Namun, kinerja membaca sekuensial 256K jauh lebih rendah dari yang saya perkirakan (100 - 200MBps, mencapai hingga 600MBps). Ketika zvol menghantam ~ 99% iowait di iostat, perangkat pendukung biasanya berjalan antara 10 dan 40% iowait, yang menunjukkan kepada saya bahwa bottleneck adalah sesuatu yang saya lewatkan dalam konfigurasi, mengingat seharusnya tidak menjadi backplane atau CPU di sistem ini, dan beban kerja berurutan seharusnya tidak bekerja terlalu keras.

Saya telah bermain sedikit dengan parameter modul (konfigurasi saat ini di bawah), membaca ratusan artikel, masalah pada OpenZFS github, dll. Prefing tuning dan agregasi membawa saya ke tingkat kinerja ini - secara default, saya berjalan sekitar ~ 50MBps pada berurutan berbunyi ketika ZFS mengirim permintaan TINY ke disk (~ 16K). Dengan agregasi dan prefetch berfungsi dengan baik (saya pikir), pembacaan disk jauh lebih tinggi, sekitar ~ 64K rata-rata di iostat.

NIC adalah target LIO iscsi dengan cxgbit offload + Windows Chelsio iscsi inisiator bekerja dengan baik di luar ZFS zvols, dengan optane yang secara langsung dipetakan mengembalikan garis-tingkat penuh penuh pada NIC (~ 3,5GBps membaca dan menulis).

Apakah saya berharap terlalu banyak? Saya tahu ZFS memprioritaskan keselamatan dibandingkan kinerja, tetapi saya berharap 7x9 raidz2 untuk memberikan bacaan berurutan yang lebih baik daripada raid6 mdadm 9-drive tunggal.

Spesifikasi sistem dan file log / konfigurasi:

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

Konfigurasi kolam:

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

Konfigurasi ZVol:

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

Tata letak kolam:

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

Aku mencabut rambutku karena ini. Tekanan dari pengguna untuk semua-Windows dengan Storage Spaces, tapi saya telah menggunakan ruang penyimpanan paritas (bahkan dengan Storage Spaces Direct dengan mirror di atas), dan itu tidak cantik juga. Saya tergoda untuk langsung menjalankan mdadm raid60 di bawah iSCSI, tetapi akan senang jika seseorang dapat menunjukkan sesuatu yang bodoh Saya tidak hadir yang akan membuka kunci kinerja dengan perlindungan bitrot ZFS :)

Pertanyaan bagus.

• Saya pikir ukuran blok zvol jarang Anda harus 128k.
• Pengaturan penjadwal ZIO Anda semua harus lebih tinggi, seperti minimum 10 dan maks 64.
• zfs_txg_timeout seharusnya lebih lama. Saya melakukan 15 atau 30-an pada sistem saya.
• Saya pikir beberapa RAIDZ3 (atau kesalahan ketik) yang berlebihan dan memainkan peran besar dalam kinerja. Bisakah Anda melakukan benchmark dengan RAIDZ2?

Sunting: Instal Netdata pada sistem dan pantau pemanfaatan dan statistik ZFS.

Edit2: Ini untuk repositori Veeam. Veeam mendukung Linux sebagai target, dan bekerja sangat baik dengan ZFS. Apakah Anda akan mempertimbangkan membandingkan itu dengan data Anda? zvols bukan kasus penggunaan ideal untuk apa yang Anda lakukan, kecuali jika muatan NIC adalah bagian penting dari solusi.