Ajuste de depuración ZFS, 141 KB / s funcionando durante 15 días

14

Un sistema bastante básico que ejecuta espejo + banda en discos sas de 7.2k rpm, no particularmente cargado. Sin dedup, compresión en todos los conjuntos de datos. Scrub ha estado funcionando durante 15 días a la velocidad de un caracol muerto. ¿Hay alguna optimización que deba hacerse o puede deberse a algún error en el hardware?

  • Dell R510 con gabinete MD1200.
  • 2x Xeon E5620
  • 48GB
  • NexentaStor 3.1.3, edición comunitaria

Alguna información:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

El spa_last_io cambia cada vez que ejecuto esto

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

Cada 5 segundos, se escriben unos 20-25 MB / s. Entre esas escrituras básicamente no hay lecturas ni escrituras.

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

¿Me están diciendo los iostatos que paso más tiempo esperando el disco de lo que debería? Específicamente la columna% b

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0

¿La latencia es un poco alta?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

Aplicamos algunos ajustes que hicieron poca diferencia. zfs_top_maxinflight establecido en 127, zfs_scrub_delay en 0 y zfs_scan_idle en 0.

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

ajuste previo mdb, observe la columna b% bastante alta

$ iostat -nx -M 5 

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

después del ajuste mdb, observe la columna b%, 80-85% de tiempo en espera ocupada

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0
zfs  nexenta 
— 3molo
fuente
¿Qué ocurrencia múltiple de iostat -XnE | grep Errores dice? Cómo se incrementa el conteo de errores?
Cero en todas las columnas
— 3molo
Qué smartctl -A /dev/diskdice sobre cada unidad (puede que tenga que instalar smartctl, no estoy seguro si viene con la instalación base).
— Chris S
1
Nada de interés, además de "Recuento de errores no medios: 8071" en un disco. Todos los discos se sientan en un JBOD (Dell MD1200) en el mismo (solo) carril sas
— 3molo

Respuestas:

11

Las operaciones de limpieza ZFS operan con algunos principios bastante cerebrales. En particular, solo pasa tiempo fregando cuando no sucede nada más. Si empuja un grupo con solo un poco de acceso a datos de manera bastante constante, el exfoliante se morirá de hambre y no hará casi nada.

Tunables para explorar, con mis notas rápidas sobre lo que hace (aunque lo vi por última vez hace un tiempo):

  • zfs_scan_idle: si se producen E / S de usuario dentro de tantos tics de reloj, retrasar la E / S de fregado mediante zfs_scrub_delay ticks de reloj
  • zfs_scrub_delay: cuántos ticks de reloj para retrasar la operación de fregado si es activado por zfs_scan_idle
  • zfs_top_maxinflight: número máximo de E / S de depuración por vdev de nivel superior
  • zfs_scrub_limit: número máximo de E / S de fregado por hoja vdev
  • zfs_scan_min_time_ms: ms mínimo para gastar por txg en operaciones de fregado
  • zfs_no_scrub_io - sin notas
  • zfs_no_scrub_prefetch: sin notas, el nombre parece implicar que no causa la captación previa en operaciones de fregado

Todos estos se pueden cambiar sobre la marcha usando "echo [sintonizable] / W0t [número]" para cambiar, y "echo [sintonizable] / D" para ver la configuración actual (que recomiendo hacer antes de cambiar).

Entonces, en teoría, y en la práctica general, si tuviera que, por ejemplo, cambiar zfs_scan_idle a 10 (o 1 - o 0, si lo admite, necesitaría verificar el código) y zfs_scrub_delay a 1 (o 0, si es compatible con eso), y si su configuración de txg_synctime_ms es 5000 o más, tal vez cambie un poco zfs_scan_min_time_ms, debería ser mucho más agresivo al hacer operaciones de fregado incluso con algún nivel de E / S de usuario.

En su caso específico,% b y asvc_t informados implican una carga de trabajo de lectura muy, muy aleatoria (los discos giratorios deberían funcionar mejor que eso si es realmente secuencial), y ya ha hecho las cosas "fáciles" como se explicó anteriormente . Entonces, primero activaría zfs_no_scrub_prefetch, para deshabilitar la captación previa en las operaciones de fregado, solo para ver si eso ayudó. Si no es divertido, dependiendo de la versión de Nexenta en la que se encuentre, puede estar ejecutando 30/5, 5/1 o 10/5 (esa es la forma abreviada que usamos para la configuración de zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Cambie zfs_txg_timeout a 10 y zfs_txg_synctime_ms a 5000, luego intente subir zfs_scan_min_time_ms a 3000 o 4000. Esto le dice a ZFS que puede pasar mucho más tiempo en scrubs, en comparación con la configuración predeterminada en las instalaciones antiguas de NexentaStor que usan 5/1 como valores predeterminados, pero Cuidado,

Espero que esto ayude. ¡Buena suerte!

— Nex7
fuente
Supongo que debería tener en cuenta que modifica estas configuraciones en bash usando "echo <tunable> / W0t <number> | mdb -kw". Y puede ver los valores actuales con "echo <tunable> / D | mdb -k". Mis notas dicen que todo esto se puede cambiar en vuelo, ninguno parece requerir una modificación / etc / system y reiniciar para que surta efecto.
— Nex7
También debería leer la pregunta completa antes de responder, y dejar de navegar por ServerFault durante las llamadas de conferencia. :)
— Nex7
Los informes% b y asvc_t implican una carga de trabajo de lectura muy, muy aleatoria (los discos giratorios deberían funcionar mejor que eso si es realmente secuencial). Primero, activaría zfs_no_scrub_prefetch, para deshabilitar la captación previa en las operaciones de fregado, solo para ver si eso ayudó. Si no hay alegría, dependiendo de la versión de Nexenta en la que se encuentre, puede estar ejecutando 30/5, 5/1 o 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000). Cambie zfs_txg_timeout a 10 y zfs_txg_synctime_ms a 5000, luego intente subir zfs_scan_min_time_ms a 3000 o 4000. Esto le dice a ZFS que puede gastar mucho más tiempo en matorrales, ¡puede matar de hambre E / S normal!
— Nex7
Creo que usted proporciona información muy valiosa, pero sería mucho más útil si pudiera agregar los comentarios en una buena respuesta.
— 3molo
2
Más ajustes pueden haber ayudado, pero no necesariamente. Es importante tener en cuenta que un scrub ZFS recorre la estructura de datos, NO sector por sector en los discos. Es decir, dependiendo de cómo se vea la estructura de datos zfs en sus discos, una operación de depuración puede parecer increíblemente aleatoria: sus discos pueden ser capaces de> 100 MB / s de lectura secuencial , pero la lectura completamente aleatoria será otra historia completamente diferente. . El tamaño promedio de bloque también sería importante aquí.
— Nex7
3

Sospecho de hardware ...

¿Por qué dejarías que esto durara 15 días? Eso no es normal. Detenga el exfoliante zpool scrub -s tanky verifique el sistema.

  • ¿Qué controladores estás usando?
  • ¿Es este el primer exfoliante que has ejecutado en este grupo?
  • ¿Hubo un problema que te llevó a ejecutar el exfoliante en primer lugar?
— ewwhite
fuente
1
LSI SAS9200-8e (firmware de TI). No primer exfoliante. No, no hay problemas reales (pero he estado cuestionando el rendimiento secuencial de lectura / escritura por un tiempo).
— 3molo
Actualizado con latencia y tiempos de espera, comienza a sospechar que siempre hay tiempo para atender las solicitudes y eso prioriza el fregado tan bajo que se detiene. Cualquier idea es muy útil!
— 3molo
Los matorrales son importantes para correr periódicamente. Esperar hasta que tenga un problema para ejecutar un scrub es pedir que ese problema explote en pérdida de datos. Los scrubs están ahí para detectar la corrupción silenciosa de datos (bitrot). Un fregado de ejecución lenta no es un signo de un problema del sistema, solo un grupo que se mantiene lo suficientemente ocupado como para no acelerar el fregado.
— lschweiss
0

Mi respuesta llega un poco tarde, pero si este tipo de cosas le sucede a alguien más, aquí está mi opinión: simplemente pruebe "dmesg". En mi caso, no estaba haciendo un exfoliante, pero estaba copiando archivos en los discos, y claramente escuché que los discos estaban activos durante unos segundos, luego se detuvieron por un tiempo más prolongado, y nuevamente funcionaron y así sucesivamente. Esto se debió a la falla de un controlador SATA y dmesg me dio todos los errores. Al principio pensé que era un disco defectuoso, pero luego me di cuenta de que en realidad era el controlador.

— jytou
fuente
-3

Scrub utiliza el tiempo de inactividad del sistema disponible, incluso en un servidor descargado, se trata de disponibilidad. Ram y Processor son las claves para la utilización del scrub, no el disco. Mientras más de estos estén disponibles, mejor será su rendimiento de limpieza. Sin embargo, ciertamente, en este caso, cuanto mejor estén dispuestos sus discos, en términos de ZPools, mejor será también el rendimiento de su scrub.

Entonces, si su rendimiento ha sido lento, y ese parece ser el caso, consideraría estos como posibles razones.

— usuario169761
fuente
1
No veo ningún indicador de que los recursos sean escasos.
— 3molo
1
Esto es casi completamente falso. La CPU y la RAM tienen un impacto cero efectivo en las operaciones de fregado (suponiendo que haya algo libre). Tener mucha RAM y CPU libres no "acelerará" las operaciones de fregado. Scrub está limitado al observar las E / S entrantes en el grupo, no al verificar el 'tiempo de inactividad del sistema disponible', sea lo que sea.
— Nex7
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.