10 votos

Velocidades secuenciales lentas en 9x7-drive raidz2 (ZFS ZoL 0.8.1)

Estoy corriendo un gran agrupación de ZFS construida de 256 KB+ tamaño de la solicitud secuencial lee y escribe a través de iSCSI (para copias de seguridad) en Ubuntu 18.04. Dada la necesidad de un alto rendimiento y aprovechamiento del espacio, y menos necesidad de azar de bloque pequeño de rendimiento, me fui con rayas raidz2 de rayas espejos.

Sin embargo, los 256 KB de rendimiento de lectura secuencial es mucho menor de lo que yo habría esperado (100 - 200 mbps, picos de hasta 600 mbps). Cuando el zvols están golpeando ~99% iowait en iostat, con el respaldo de los dispositivos típicamente entre 10 y 40% iowait, que me sugiere el cuello de botella es algo que me estoy perdiendo en la configuración, dado que no debería ser el plano posterior o Cpu en este sistema, y secuencial de las cargas de trabajo no debe trabajar el ARCO demasiado duro.

He jugado un poco con los parámetros del módulo (configuración actual de abajo), leer cientos de artículos, temas en OpenZFS github, etc. Optimización prefetch y agregación de llegar a este nivel de rendimiento - por defecto, yo estaba corriendo en alrededor de ~50 mbps en lecturas secuenciales como ZFS fue el envío de PEQUEÑAS peticiones a los discos (~16 KB). Con la agregación y prefetch funciona bien (creo), lecturas de disco son mucho más altos, alrededor de ~64 KB en promedio en iostat.

Nic LIO de destino iscsi con cxgbit de descarga + Windows Chelsio iniciador iscsi de trabajo fuera de ZFS zvols, con un optane directamente asignada volver casi completo de la velocidad de línea en el Nic (~3.5 GBps leer y escribir).

Estoy esperando demasiado? Sé ZFS prioriza la seguridad de los más de rendimiento, pero me gustaría esperar un 7x9 raidz2 para proporcionar una mejor lecturas secuenciales de una sola 9-unidad de mdadm raid6.

Especificaciones del sistema y los 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 grupo:

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

ZVol de configuración:

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

Piscina de diseño:

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 tirando de los pelos en esto. La presión del en de los usuarios para ir all-Windows con Espacios de Almacenamiento, pero he utilizado la paridad de espacios de almacenamiento (incluso con Espacios de Almacenamiento Directo con espejos en la parte superior), y no muy bien. Estoy tentado de ir directamente mdadm raid60 bajo iSCSI, pero me encantaría que si alguien podría señalar algo estúpido que me falta, que va a desbloquear el rendimiento con el bitrot protección de ZFS :)

7voto

Tina Puntos 21

Buena pregunta.

  • Creo que su escasa zvol tamaño de bloque debe ser de 128k.
  • Su ZIO la configuración del programador, todas deben ser más altos, como mínimo de 10 y máximo de 64.
  • zfs_txg_timeout debería ser mucho más larga. Hago 15 o 30 años en mis sistemas.
  • Creo que las múltiples RAIDZ3 es (o fue un error de tipeo) son una exageración y juegan un papel importante en el rendimiento. Puede medir con RAIDZ2?

Edit: Instale Netdata en el sistema y vigilar la utilización y ZFS de estadísticas.

Edit2: Esto es para un Veeam repositorio. Veeam apoyar a Linux como un objetivo, y funciona de maravilla con ZFS. Se consideraría la posibilidad de benchmarking que con sus datos? zvols no es un ideal de caso de uso para lo que estás haciendo, a menos que la NIC, la descarga es una parte crítica de la solución.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: