tl;dr: Mi matriz ZFS RAIDZ2 lee a más de 7,5 GB/s y escribe a más de 2,0 GB/s cuando especifico un bs=128Kvalor o superior con dd. OS X asume 1K (según stat -f %k .) y todo mi es ~300MB/s; ddda el mismo rendimiento con bs=1k. Incluso un bs=4kda 1,1 GB/s con dd.
¿Qué puedo hacer para mejorar la E/S general a al menos 1 GB/s?
--
Detalles:
Estoy ejecutando un SATA3 RAIDZ2 OpenZFS de 16 unidades en un sistema de archivos OSX (v1.31r2) (v5000) sobre Thunderbolt 2 (Areca 8050T2 gemelos) en una Mac Pro de 12 núcleos y 64 GB.
El sistema de archivos ZFS se creó con ashift=12(HDD de formato avanzado con bloques de 4096 bytes) y un archivo recordsize=128k.
Veo tasas de transferencia de alrededor de 300 MB/s desde la matriz en OS X y desde el terminal usando comandos predeterminados (tenga en cuenta que el archivo que se copia tiene 10 GB de datos aleatorios):
Copia normal:
Titanic:lb-bu admin$ time cp big-test.data /dev/null
real 0m23.730s
user 0m0.005s
sys 0m12.123s
≈ 424 MB/s
--
ddcon bs=1k:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)
real 0m32.575s
user 0m1.880s
sys 0m30.695s
≈ 309 MB/s
--
ddconbs=4k
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)
real 0m8.688s
user 0m0.460s
sys 0m8.228s
≈1,16 GB/s
--
ddcon bs=2m:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)
real 0m1.165s
user 0m0.003s
sys 0m1.162s
≈8,67 GB/s
--
OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096
--
OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024
--
También creé un volumen ZFS en el grupo junto con el sistema de archivos y lo formateé como HFS+. Obtuve el mismo rendimiento que el anterior.
¡Estoy funcionando entre 20 y 30 veces por debajo del nivel óptimo! ¿Qué me estoy perdiendo? ¿Algunas ideas?
--
Actualización: Las altas velocidades fueron E/S almacenadas en caché (gracias @yoonix). Velocidades de ≈300 MB/s todavía parecen demasiado lentas para este hardware.
@qasdfdsaq: La utilización de la CPU durante la E/S es insignificante (todos los núcleos <5%).
zfs obtiene todos los resultados:
NAME PROPERTY VALUE SOURCE
lb-bu type filesystem -
lb-bu creation Tue Sep 30 16:41 2014 -
lb-bu used 36.8T -
lb-bu available 10.0T -
lb-bu referenced 138M -
lb-bu compressratio 1.00x -
lb-bu mounted yes -
lb-bu quota none default
lb-bu reservation none default
lb-bu recordsize 128K default
lb-bu mountpoint /Volumes/lb-bu local
lb-bu sharenfs off default
lb-bu checksum on default
lb-bu compression lz4 local
lb-bu atime on default
lb-bu devices on default
lb-bu exec on default
lb-bu setuid on default
lb-bu readonly off default
lb-bu zoned off default
lb-bu snapdir hidden default
lb-bu aclmode discard default
lb-bu aclinherit restricted default
lb-bu canmount on default
lb-bu xattr on default
lb-bu copies 1 default
lb-bu version 5 -
lb-bu utf8only on -
lb-bu normalization formD -
lb-bu casesensitivity insensitive -
lb-bu vscan off default
lb-bu nbmand off default
lb-bu sharesmb off default
lb-bu refquota none default
lb-bu refreservation none default
lb-bu primarycache all default
lb-bu secondarycache all default
lb-bu usedbysnapshots 0 -
lb-bu usedbydataset 138M -
lb-bu usedbychildren 36.8T -
lb-bu usedbyrefreservation 0 -
lb-bu logbias latency default
lb-bu dedup off default
lb-bu mlslabel none default
lb-bu sync standard default
lb-bu refcompressratio 1.01x -
lb-bu written 138M -
lb-bu logicalused 36.8T -
lb-bu logicalreferenced 137M -
lb-bu snapdev hidden default
lb-bu com.apple.browse on default
lb-bu com.apple.ignoreowner off default
lb-bu com.apple.mimic_hfs off default
lb-bu redundant_metadata all default
lb-bu overlay off default
Respuesta1
No publicaste esto zpool status, pero implicas en la publicación que los 16 discos están en un solo vdev en RAIDZ2. Si bien esta es una configuración buena y segura, debes comprender que RAIDZ no está diseñado principalmente para la velocidad. Está diseñado para ser casi a prueba de balas. RAIDZ2 es análogo a RAID6 pero la variante tiene características que lo hacen más lento y seguro.
Vereste lindo escritopara obtener todos los detalles, pero estas dos citas deberían ayudarle a ver el problema (el énfasis es mío):
Al escribir en RAID-Z vdev, cada bloque del sistema de archivos se divide en su propia franja en (potencialmente) todos los dispositivos del RAID-Z vdev. Esto significa que cada E/S de escritura tendrá que esperar hasta que todos los discos en RAID-Z vdev hayan terminado de escribir. Por lo tanto, desde el punto de vista de una única aplicación esperando a que se complete su IO,Obtendrá el rendimiento de escritura de IOPS del disco más lento en RAID-Z vdev.
Al leer desde RAID-Z vdevs, se aplican las mismas reglas, ya que el proceso se invierte esencialmente (sin atajos por turnos como en el caso de la duplicación): mejor ancho de banda si tiene suerte (y lea de la misma manera que escribió)y el rendimiento de lectura de IOPS de un solo disco en la mayoría de los casos importantes.
En efecto, tiene 16 unidades de velocidad media y para cada paso de escritura, espera a que las 16 unidades se registren con el controlador y digan "listo" antes de que comience la siguiente escritura. Con 16 discos, efectivamente siempre esperará una rotación casi completa del disco antes de una de las escrituras, por lo que la física y la forma en que ZFS confirma los datos lo retrasan.
La tarea de escritura de subproceso/proceso único no es el mejor caso para ZFS en general. La ejecución de varias tareas de lectura/escritura de datos pequeños a la vez puede mostrar mejores números de IOPS, pero creo que la física de ZFS es su principal problema.
Si está dispuesto a sacrificar el espacio, la duplicación probablemente sea más rápida. También puede obtener un rendimiento marginalmente mejor de ZFS creando 2 vdev RAIDZ2 de 8 discos en el grupo en lugar de 1 vdev RAIDZ2 de 16 discos. Esto también le costará espacio de almacenamiento utilizable, pero puede ayudar a que las confirmaciones se realicen más rápido.
Lamentablemente no tengo buenas noticias para ti.