Lectura secuencial lenta del grupo ZFS

Tengo una pregunta relacionada con este problema, pero se volvió demasiado complicado y demasiado grande, así que decidí dividir el problema en NFS y problemas locales. También he intentado preguntar sobre esto en la lista de correo zfs-debates sin mucho éxito.

Copia lenta entre directorios NFS / CIFS en el mismo servidor

Esquema: cómo estoy configurado y qué espero

1. Tengo un grupo ZFS con 4 discos. ROJO de 2TB configurado como 2 espejos rayados (RAID 10). En Linux, zfsonlinux. No hay caché o dispositivos de registro.
2. Los datos se equilibran en los espejos (importante para ZFS)
3. Cada disco puede leer (sin formato w / dd) a 147MB / seg en paralelo, dando un rendimiento combinado de 588MB / seg.
4. Espero unos 115 MB / seg. De escritura, 138 MB / seg. De lectura y 50 MB / seg. De reescritura de datos secuenciales de cada disco, según los puntos de referencia de un disco RED de 4 TB similar. Espero no menos de 100 MB / seg de lectura o escritura, ya que cualquier disco puede hacer eso en estos días.
5. Pensé que vería un 100% de utilización de E / S en los 4 discos cuando estaba bajo carga o escribiendo datos secuenciales. Y que los discos estarían produciendo más de 100 MB / seg mientras que están al 100% de utilización.
6. Pensé que el grupo me daría alrededor de 2x de escritura, 2x de reescritura y 4x de rendimiento de lectura en un solo disco. ¿Me equivoco?
7. NUEVO Pensé que un zvol ext4 en el mismo grupo tendría aproximadamente la misma velocidad que ZFS

Lo que realmente obtengo

Creo que el rendimiento de lectura del grupo no es tan alto como esperaba

Bonnie ++ benchmark en el grupo de hace unos días

Versión 1.97 ------ Salida secuencial ------ - Entrada secuencial- --Random-
Concurrencia 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Tamaño de la máquina K / seg.% CP K / seg.% CP K / seg.% CP K / seg.% CP K / seg.% CP / seg.% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6

bonnie ++ en una sola unidad RED de 4TB por sí misma en un zpool

Versión 1.97 ------ Salida secuencial ------ - Entrada secuencial- --Random-
Concurrencia 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Tamaño de la máquina K / seg.% CP K / seg.% CP K / seg.% CP K / seg.% CP K / seg.% CP / seg.% CP
igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111,6 8

De acuerdo con esto, las velocidades de lectura y reescritura son apropiadas en función de los resultados de un solo disco RED de 4TB (son dobles). Sin embargo, la velocidad de lectura que esperaba habría sido de aproximadamente 550 MB / seg (4 veces la velocidad de la unidad de 4 TB) y al menos esperaría alrededor de 400 MB / seg. En cambio, estoy viendo alrededor de 260 MB / seg.

bonnie ++ en la piscina desde hace un momento, mientras recopila la información a continuación. No es lo mismo que antes, y nada ha cambiado.

Versión 1.97 ------ Salida secuencial ------ - Entrada secuencial- --Random-
Concurrencia 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Tamaño de la máquina K / seg.% CP K / seg.% CP K / seg.% CP K / seg.% CP K / seg.% CP / seg.% CP
igor 63G 103 99 207518 43 108810 24342 98 302350 26 256.4 18

iostato zpool durante la escritura. Me parece bien.

                                                 ancho de banda de operaciones de capacidad
grupo aloc lectura libre escritura lectura lectura escritura
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
  espejo 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1.60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  espejo 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0953 0 117M

zpool iostat durante la reescritura. Me parece bien, creo .

                                                 ancho de banda de operaciones de capacidad
grupo aloc lectura libre escritura lectura lectura escritura
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 1015923 125M 101M
  espejo 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198438 24.4M 51.7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306384 37.8M 45.1M
  espejo 651G 1.18T 510457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304371 37.8M 43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25.5M 49.6M

Aquí es donde me pregunto qué está pasando.

iostato zpool durante la lectura

                                                 ancho de banda de operaciones de capacidad
grupo aloc lectura libre escritura lectura lectura escritura
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  espejo 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92.5M 96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76.8M 96.8K
  espejo 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95.7M 56.0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74.0M 56.0K

iostat -x durante la misma operación de lectura. Observe cómo IO% no está al 100%.

Dispositivo: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz await r_await w_await svctm% util
sdb 0.60 0.00 661.30 6.00 83652.80 49.20 250.87 2.32 3.47 3.46 4.87 1.20 79.76
sdd 0.80 0.00 735.40 5.30 93273.20 49.20 251.98 2.60 3.51 3.51 4.15 1.20 89.04
sdf 0.50 0.00 656.70 3.80 83196.80 31.20 252.02 2.23 3.38 3.36 6.63 1.17 77.12
sda 0.70 0.00 738.30 3.30 93572.00 31.20 252.44 2.45 3.33 3.31 7.03 1.14 84.24

Configuración de conjunto de datos de prueba y zpool:

• atime está apagado
• la compresión está desactivada
• ashift es 0 (autodetección - entiendo que esto estaba bien)
• zdb dice que los discos son todos ashift = 12
• módulo - opciones zfs zvol_threads = 32 zfs_arc_max = 17179869184
• sincronización = estándar

Editar - 30 de octubre de 2015

Hice algunas pruebas más

• conjunto de datos bonnie ++ w / recordsize = 1M = 226MB de escritura, 392MB de lectura mucho mejor
• conjunto de datos dd con tamaño de registro = 1 M = 260 MB de escritura, 392 MB de lectura mucho mejor
• zvol w / ext4 dd bs = 1M = 128MB de escritura, 107MB de lectura ¿por qué tan lento?
• conjunto de datos 2 procesos en paralelo = 227 MB de escritura, 396 MB de lectura
• dd direct io no hace ninguna diferencia en el conjunto de datos y en zvol

Estoy mucho más feliz con el rendimiento con el mayor tamaño de grabación. Casi todos los archivos del grupo tienen más de 1 MB. Así que lo dejaré así. Los discos todavía no obtienen el 100% de utilización, lo que me hace preguntarme si aún podría ser mucho más rápido. Y ahora me pregunto por qué el rendimiento de zvol es tan malo, ya que es algo que uso (a la ligera).

Me complace proporcionar cualquier información solicitada en los comentarios / respuestas. También hay toneladas de información publicada en mi otra pregunta: copia lenta entre directorios NFS / CIFS en el mismo servidor

Soy plenamente consciente de que es posible que no entienda algo y que esto no sea un problema en absoluto. Gracias por adelantado.

Para que quede claro, la pregunta es: ¿por qué el conjunto de ZFS no es tan rápido como esperaba? ¿Y quizás hay algo más mal?

Logré obtener velocidades muy cercanas a los números que esperaba.

Estaba buscando 400 MB / seg y logré 392 MB / seg . Por eso digo que está resuelto el problema. Con la adición posterior de un dispositivo de caché, logré una lectura de 458 MB / seg (creo que en caché).

1. Esto al principio se logró simplemente aumentando el recordsizevalor del conjunto de datos ZFS a1M

zfs set recordsize=1M pool2/test

Creo que este cambio solo da como resultado una menor actividad del disco, por lo tanto, lecturas y escrituras sincrónicas grandes más eficientes. Exactamente lo que estaba pidiendo.

Resultados después del cambio

• bonnie ++ = 226 MB de escritura, 392 MB de lectura
• dd = 260 MB de escritura, 392 MB de lectura
• 2 procesos en paralelo = 227 MB de escritura, 396 MB de lectura

2. Me las arreglé aún mejor cuando agregué un dispositivo de caché (SSD de 120 GB). La escritura es un poco más lenta, no estoy seguro de por qué.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

El truco con el dispositivo de caché fue configurar l2arc_noprefetch=0en /etc/modprobe.d/zfs.conf . Permite a ZFS almacenar en caché la transmisión / datos secuenciales. Solo haga esto si su dispositivo de caché es más rápido que su matriz, como el mío.

Después de beneficiarme del cambio de tamaño de registros en mi conjunto de datos, pensé que podría ser una forma similar de lidiar con un bajo rendimiento de zvol.

Me encontré con diecisiete personas que mencionaron que obtuvieron un buen rendimiento usando un volblocksize=64k, así que lo probé. Sin suerte.

zfs create -b 64k -V 120G pool/volume

Pero luego leí que ext4 (el sistema de archivos con el que estaba probando) admite opciones para RAID stridey stripe-width, que nunca he usado antes. Así que utilicé este sitio para calcular la configuración necesaria: https://busybox.net/~aldot/mkfs_stride.html y formateé el zvol nuevamente.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Corrí bonnie++para hacer un punto de referencia simple y los resultados fueron excelentes. Lamentablemente, no tengo los resultados conmigo, pero al menos fueron 5-6 veces más rápidos para las escrituras, según recuerdo. Actualizaré esta respuesta nuevamente si comparo nuevamente.

Sus resultados son perfectamente razonables, mientras que sus expectativas no lo son: exagera la mejora del rendimiento de lectura dada por RAID1 (y, por extensión, por RAID10). El punto es que una duplicación de 2 vías da como máximo 2 veces la velocidad de lectura / IOP del disco único, pero el rendimiento en el mundo real puede estar entre 1x-2x.

Aclaremos con un ejemplo. Imagine tener un sistema con espejo de 2 vías, con cada disco capaz de 100 MB / s (secuencial) y 200 IOPS. Con una profundidad de cola de 1 (máximo una individual, solicitud pendiente) esta matriz tendrá ninguna ventaja sobre un solo disco: RAID 1 se divide solicitudes IO en la cola de los dos del disco, pero sí no divide una única solicitud en dos discos (al menos, cualquier implementación que vi se comportó de esta manera). Por otro lado, si su cola de E / S es mayor (por ejemplo, tiene 4/8 solicitudes pendientes), el rendimiento total del disco será significativamente mayor que el de un solo disco.

Se puede hacer un punto similar para RAID0, pero en este caso lo que determina las mejoras promedio es una función no solo del tamaño de la cola, sino también del tamaño de la solicitud de E / S : si su tamaño promedio de E / S es menor que el tamaño del fragmento, entonces no se dividirá en dos (o más) discos, pero será atendido por uno solo. Sus resultados con el mayor tamaño de registro de Bonnie ++ muestran este comportamiento exacto: las bandas se benefician enormemente de un mayor tamaño de E / S.

Ahora debe quedar claro que la combinación de los dos niveles RAID en una matriz RAID10 no conducirá a una escala de rendimiento lineal, pero establece un límite superior para ello. Estoy bastante seguro de que si ejecuta varias instancias de dd / bonnie ++ (o las usa fiopara manipular directamente la cola IO) tendrá resultados más acordes con sus expectativas originales, simplemente porque gravará su matriz IO de una manera más completa ( múltiples solicitudes de E / S secuenciales / aleatorias sobresalientes), en lugar de cargarlas solo de solicitudes de E / S secuenciales y únicas.