Niskie sekwencyjne prędkości na 9x7 dysku raidz2 (ZFS ZoL 0.8.1)

Korzystam z dużej puli ZFS zbudowanej dla sekwencyjnych odczytów i żądań o wielkości 256 KB i więcej przez iSCSI (dla kopii zapasowych) na Ubuntu 18.04. Biorąc pod uwagę potrzebę wysokiej przepustowości i wydajności przestrzeni, a także mniejszą potrzebę losowej wydajności w małych blokach, zdecydowałem się na paski raidz2 na paski lusterek.

Jednak wydajność odczytu sekwencyjnego 256 KB jest znacznie niższa niż się spodziewałem (100-200 MB / s, maksimum do 600 MB / s). Kiedy wartości Zvols osiągają ~ 99% iowait w iostacie, urządzenia bazowe zwykle działają między 10 a 40% iowait, co sugeruje mi, że wąskim gardłem jest coś, czego brakuje mi w konfiguracji, biorąc pod uwagę, że nie powinien to być backplane lub procesory w ten system i kolejne obciążenia nie powinny zbyt mocno obciążać ARC.

Grałem sporo z parametrami modułu (obecna konfiguracja poniżej), czytałem setki artykułów, problemy na githubie OpenZFS itp. Dostrajanie pobierania wstępnego i agregacji doprowadziło mnie do tego poziomu wydajności - domyślnie działałem z prędkością około ~ 50 MB / s na sekwencyjne odczyty, gdy ZFS wysyłał TINY żądania na dyski (~ 16K). Przy agregacji i pobraniu wstępnym działa (myślę), odczyty dysku są znacznie wyższe, średnio około ~ 64 KB w iostacie.

Karty sieciowe są celem LIO iscsi z odciążeniem cxgbit + Windows Inicjator Chelsio iscsi działa dobrze poza Zvols ZFS, z opcją mapowania bezpośrednio zwracającą prawie pełną szybkość linii na kartach sieciowych (~ 3,5 GB / s odczytu i zapisu).

Czy oczekuję zbyt wiele? Wiem, że ZFS stawia na bezpieczeństwo ponad wydajność, ale spodziewam się, że 7x9 raidz2 zapewni lepsze sekwencyjne odczyty niż pojedynczy 9-dyskowy mdadm raid6.

Specyfikacje systemowe i dzienniki / pliki konfiguracyjne:

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

Konfiguracja basenu:

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

Konfiguracja ZVol:

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

Układ basenu:

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

Obdzieram z tego włosy. Presja ze strony użytkowników, aby przejść na wszystkie systemy Windows z pamięcią masową, ale użyłem parzystych przestrzeni dyskowych (nawet z Storage Spaces Direct z lustrem na górze), i to też nie jest ładne. Kusi mnie, aby przejść prosto do mdadm raid60 pod iSCSI, ale chciałbym, aby ktoś mógł wskazać coś, co mnie zdziwiło, którego brakuje, co odblokuje wydajność dzięki ochronie bitrotu w ZFS :)

Dobre pytanie.

• Myślę, że twój rzadki rozmiar bloku Zvol powinien wynosić 128k.
• Wszystkie ustawienia harmonogramu ZIO powinny być wyższe, na przykład minimum 10 i maksimum 64.
• zfs_txg_timeout powinien być znacznie dłuższy. Robię 15 lub 30 lat na moich systemach.
• Myślę, że wiele RAIDZ3 (lub literówka) to przesada i odgrywają dużą rolę w wydajności. Czy potrafisz przeprowadzić testy porównawcze z RAIDZ2?

Edycja: zainstaluj Netdata w systemie i monitoruj wykorzystanie oraz statystyki ZFS.

Edycja2: To dotyczy repozytorium Veeam. Veeam wspiera Linuksa jako cel i wspaniale współpracuje z ZFS. Czy zastanowiłbyś się nad porównaniem tego ze swoimi danymi? zvols nie są idealnym przykładem użycia do tego, co robisz, chyba że odciążenie karty sieciowej jest krytyczną częścią rozwiązania.