Estoy ejecutando un gran grupo de ZFS creado para lecturas y escrituras secuenciales de 256K + de tamaño de solicitud a través de iSCSI (para copias de seguridad) en Ubuntu 18.04. Dada la necesidad de un alto rendimiento y eficiencia de espacio, y menos necesidad de un rendimiento aleatorio de bloque pequeño, opté por raidz2 rayado sobre espejos rayados.
Sin embargo, el rendimiento de lectura secuencial de 256K es mucho más bajo de lo que esperaba (100 - 200MBps, picos de hasta 600MBps). Cuando los zvols alcanzan ~ 99% de iowait en iostat, los dispositivos de respaldo generalmente se ejecutan entre 10 y 40% de iowait, lo que me sugiere que el cuello de botella es algo que me falta en la configuración, dado que no debería ser el backplane o las CPU en este sistema, y las cargas de trabajo secuenciales no deberían trabajar demasiado el ARC.
He jugado bastante con los parámetros del módulo (configuración actual a continuación), leí cientos de artículos, problemas con OpenZFS github, etc. La captación previa y la agregación de ajustes me llevaron a este nivel de rendimiento; de forma predeterminada, estaba ejecutando a aproximadamente ~ 50 MBps en lecturas secuenciales ya que ZFS estaba enviando solicitudes TINY a los discos (~ 16K). Con la agregación y la captación previa funcionando bien (creo), las lecturas de disco son mucho más altas, alrededor de ~ 64K en promedio en iostat.
Las NIC son un objetivo iscsi de LIO con descarga cxgbit + El iniciador iscsi de Windows Chelsio funciona bien fuera de los zvols de ZFS, con un optano directamente mapeado que devuelve una velocidad de línea casi completa en las NIC (~ 3.5GBps de lectura y escritura).
¿Estoy esperando demasiado? Sé que ZFS prioriza la seguridad sobre el rendimiento, pero esperaría que un raidz2 7x9 proporcione mejores lecturas secuenciales que un solo raid6 mdadm de 9 unidades.
Especificaciones del sistema y registros / archivos de configuración:
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
Configuración de la piscina:
ashift=12
recordsize=128K (blocks on zvols are 64K, below)
compression=lz4
xattr=sa
redundant_metadata=most
atime=off
primarycache=all
Configuración de ZVol:
sparse
volblocksize=64K (matches OS allocation unit on top of iSCSI)
Diseño de la 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
Me estoy arrancando el pelo por esto. Los usuarios presionan para ir a Windows con espacios de almacenamiento, pero he usado espacios de almacenamiento de paridad (incluso con Storage Spaces Direct con espejos en la parte superior), y tampoco es bonito. Estoy tentado a ir directamente a mdadm raid60 bajo iSCSI, pero me encantaría que alguien pudiera señalar algo descabellado que me falta que desbloqueará el rendimiento con la protección bitrot de ZFS :)