Ralentizaciones extremas de ZFS después de varios meses

8

Tengo un servidor de uso general, que proporciona correo, DNS, web, bases de datos y algunos otros servicios para varios usuarios.

Tiene un Xeon E3-1275 a 3.40 GHz, 16 GB de RAM ECC. Ejecutando Linux kernel 4.2.3, con ZFS-on-Linux 0.6.5.3.

El diseño del disco es 2x unidades Seagate ST32000641AS de 2 TB y 1x SSD Samsung 840 Pro de 256 GB

Tengo las 2 HD en un espejo RAID-1, y el SSD está actuando como un dispositivo de caché y registro, todo administrado en ZFS.

Cuando configuré el sistema por primera vez, fue increíblemente rápido. No hay puntos de referencia reales, solo ... rápido.

Ahora, noto ralentizaciones extremas, especialmente en el sistema de archivos que contiene todos los maildirs. Hacer una copia de seguridad nocturna lleva más de 90 minutos por solo 46 GB de correo. A veces, la copia de seguridad provoca una carga tan extrema que el sistema casi no responde durante hasta 6 horas.

He corrido zpool iostat zroot(mi grupo se llama zroot) durante estas ralentizaciones, y he visto escrituras en el orden de 100-200kbytes / seg. No hay errores de E / S obvios, el disco no parece estar trabajando particularmente duro, pero la lectura es inusualmente lenta.

Lo extraño es que tuve exactamente la misma experiencia en una máquina diferente, con hardware de especificaciones similares, aunque sin SSD, ejecutando FreeBSD. Funcionó bien durante meses, luego se ralentizó de la misma manera.

Mi sospecha es la siguiente: uso zfs-auto-snapshot para crear instantáneas continuas de cada sistema de archivos. Crea instantáneas de 15 minutos, por hora, diariamente y mensualmente, y mantiene un cierto número de cada una, eliminando las más antiguas. Significa que, con el tiempo, se han creado y destruido miles de instantáneas en cada sistema de archivos. Es la única operación de nivel de sistema de archivos en curso que se me ocurre con un efecto acumulativo. Intenté destruir todas las instantáneas (pero mantuve el proceso ejecutándose, creando nuevas), y no noté ningún cambio.

¿Hay algún problema con la creación y destrucción constantes de instantáneas? Considero que tenerlos es una herramienta extremadamente valiosa, y se me ha hecho creer que (aparte del espacio en disco) tienen un costo más o menos cero.

¿Hay algo más que pueda estar causando este problema?

EDITAR: salida de comando

Salida de zpool list:

NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
zroot  1.81T   282G  1.54T         -    22%    15%  1.00x  ONLINE  -

Salida de zfs list:

NAME             USED  AVAIL  REFER  MOUNTPOINT
zroot            282G  1.48T  3.55G  /
zroot/abs       18.4M  1.48T  18.4M  /var/abs
zroot/bkup      6.33G  1.48T  1.07G  /bkup
zroot/home       126G  1.48T   121G  /home
zroot/incoming  43.1G  1.48T  38.4G  /incoming
zroot/mail      49.1G  1.48T  45.3G  /mail
zroot/mailman   2.01G  1.48T  1.66G  /var/lib/mailman
zroot/moin       180M  1.48T   113M  /usr/share/moin
zroot/mysql     21.7G  1.48T  16.1G  /var/lib/mysql
zroot/postgres  9.11G  1.48T  1.06G  /var/lib/postgres
zroot/site       126M  1.48T   125M  /site
zroot/var       17.6G  1.48T  2.97G  legacy

Este no es un sistema muy ocupado, en general. Los picos en el gráfico a continuación son copias de seguridad nocturnas:

Estadísticas IO

Me las arreglé para atrapar el sistema durante una desaceleración (comenzando alrededor de las 8 de esta mañana). Algunas operaciones son bastante receptivas, pero el promedio de carga es actualmente de 145 y zpool listsimplemente se bloquea. Grafico:

/ dev / sdb latencia

calamares
fuente
Por favor mostrar zpool listy zfs list.
ewwhite
¿Está su piscina casi un 80% llena? Eso podría causar problemas.
Ryan Babchishin
Oh no ... ZFS root en Linux. Hmm ... ¿Has hecho alguna afinación? Además, puede estar sufriendo de fragmentación. ¿Cuál es tu versión de ZoL? ¿Has actualizado en absoluto?
ewwhite
Si estoy leyendo las cosas correctamente, zpool es la versión 28, zfs es la versión 5. No está cerca del 80% de su capacidad (¿más como el 16% de la capacidad?). ZoL es el último, 0.6.5.3.
Kaolin Fire
También se sugirió que el SSD podría estar fallando bajo un uso intensivo como registro, pero SMART dice que está funcionando bien, creo. Reallocated_Sector_Ct 0, Wear_Leveling_Count valor bruto 402 (y el valor es 88), sin errores ...
Kaolin Fire

Respuestas:

1

Mire arc_meta_used y arc_meta_limit. Con una gran cantidad de archivos pequeños, puede llenar el caché de metadatos en RAM, por lo que debe buscar información en el disco y ralentizar el mundo.

No estoy seguro de cómo hacer esto en Linux, mi experiencia es en FreeBSD.

Aaron Tomosky
fuente
Interesante, ¡gracias! Agregar github.com/zfsonlinux/zfs/issues/1261 como referencia. raíz del caos: ~ # cat / proc / spl / kstat / zfs / arcstats | grep arc_meta_used arc_meta_used 4 5895985776 raíz del caos: ~ # cat / proc / spl / kstat / zfs / arcstats | grep arc_meta_limit arc_meta_limit 4 6301327872
Kaolin Fire
Sin embargo, mirando las tasas de E / S del disco, no parece que haya mucha actividad física en el disco.
Squidpickles