Velocità sequenziali lente su raidz2 a 9x7 unità (ZFS ZoL 0.8.1)

Sto eseguendo un grande pool ZFS creato per 256 KB + letture e scritture sequenziali di dimensioni richieste tramite iSCSI (per backup) su Ubuntu 18.04. Data la necessità di un'elevata produttività ed efficienza dello spazio e meno necessità di prestazioni casuali di piccoli blocchi, sono andato con il raidz2 a strisce sugli specchi a strisce.

Tuttavia, le prestazioni di lettura sequenziale di 256 K sono di gran lunga inferiori a quanto mi sarei aspettato (100-200 Mbps, picchi fino a 600 Mbps). Quando gli zvol colpiscono circa il 99% di iowait in iostat, i dispositivi di supporto in genere funzionano tra il 10 e il 40% di iowait, il che mi suggerisce che il collo di bottiglia è qualcosa che mi manca nella configurazione, dato che non dovrebbe essere il backplane o le CPU in questo sistema e i carichi di lavoro sequenziali non dovrebbero lavorare troppo duramente l'ARC.

Ho giocato un bel po 'con i parametri del modulo (configurazione attuale sotto), ho letto centinaia di articoli, problemi su OpenZFS github, ecc. L'ottimizzazione del prefetch e dell'aggregazione mi hanno portato a questo livello di prestazioni - per impostazione predefinita, stavo funzionando a circa 50 Mbps su letture sequenziali mentre ZFS stava inviando TINY richieste ai dischi (~ 16K). Con l'aggregazione e il prefetch funzionano bene (penso), le letture del disco sono molto più alte, circa ~ 64K in iostat.

Le schede NIC sono target iscsi LIO con offload cxgbit + l'iniziatore iscsi Chelsio di Windows funziona bene al di fuori degli zvols ZFS, con un optano direttamente mappato che restituisce una frequenza quasi piena sulle NIC (~ 3,5 GBps in lettura e scrittura).

Mi aspetto troppo? So che ZFS privilegia la sicurezza rispetto alle prestazioni, ma mi aspetto che un raidz2 7x9 fornisca letture sequenziali migliori rispetto a un singolo raid6 mdadm a 9 unità.

Specifiche di sistema e file di registro / configurazione:

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

Configurazione del pool:

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

Configurazione ZVol:

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

Layout della piscina:

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

Mi sto strappando i capelli per questo. La pressione degli utenti è quella di utilizzare tutte le finestre con Spazi di archiviazione, ma ho usato spazi di archiviazione di parità (anche con Spazi di archiviazione diretti con mirror in alto), e non è nemmeno carino. Sono tentato di andare dritto su mdadm raid60 con iSCSI, ma mi piacerebbe che qualcuno potesse sottolineare qualcosa che mi manca e che sbloccherà le prestazioni con la protezione bitrot di ZFS :)

Buona domanda.

• Penso che la dimensione del tuo blocco zvol dovrebbe essere di 128k.
• Le impostazioni dello scheduler ZIO dovrebbero essere tutte più alte, come minimo 10 e massimo 64.
• zfs_txg_timeout dovrebbe essere molto più lungo. Faccio 15 o 30 secondi sui miei sistemi.
• Penso che i multipli RAIDZ3 (o era un errore di battitura) siano eccessivi e abbiano un ruolo importante nelle prestazioni. Puoi eseguire il benchmark con RAIDZ2?

Modifica: installa Netdata sul sistema e monitora l'utilizzo e le statistiche ZFS.

Edit2: questo è per un repository Veeam. Veeam supporta Linux come destinazione e funziona meravigliosamente con ZFS. Considereresti di confrontarlo con i tuoi dati? zvols non è un caso d'uso ideale per quello che stai facendo, a meno che l'offload della scheda di rete sia una parte fondamentale della soluzione.