Ralentissements extrêmes de ZFS après plusieurs mois

J'ai un serveur à usage général, fournissant du courrier, du DNS, du Web, des bases de données et d'autres services pour un certain nombre d'utilisateurs.

Il a un Xeon E3-1275 à 3,40 GHz, 16 Go de RAM ECC. Exécution du noyau Linux 4.2.3, avec ZFS-on-Linux 0.6.5.3.

La configuration du disque est de 2 disques Seagate ST32000641AS 2 To et 1 SSD Samsung 840 Pro 256 Go

J'ai les 2 disques durs dans un miroir RAID-1, et le SSD agit comme un périphérique de cache et de journal, tous gérés en ZFS.

Quand j'ai installé le système pour la première fois, c'était incroyablement rapide. Aucune référence réelle, juste ... rapide.

Maintenant, je constate des ralentissements extrêmes, en particulier sur le système de fichiers contenant tous les répertoires de messagerie. Faire une sauvegarde nocturne prend plus de 90 minutes pour seulement 46 Go de courrier. Parfois, la sauvegarde entraîne une charge si extrême que le système ne répond presque pas pendant jusqu'à 6 heures.

J'ai exécuté zpool iostat zroot(mon pool est nommé zroot) pendant ces ralentissements et j'ai vu des écritures de l'ordre de 100 à 200 Ko / s. Il n'y a pas d'erreurs d'E / S évidentes, le disque ne semble pas travailler particulièrement dur, mais la lecture est presque inhabituellement lente.

Ce qui est étrange, c'est que j'ai eu exactement la même expérience sur une machine différente, avec du matériel de spécifications similaires, mais pas de SSD, exécutant FreeBSD. Cela a bien fonctionné pendant des mois, puis s'est ralenti de la même manière.

Ma suspicion est la suivante: j'utilise zfs-auto-snapshot pour créer des instantanés déroulants de chaque système de fichiers. Il crée des instantanés de 15 minutes, horaires, quotidiens et mensuels, et conserve un certain nombre de chacun, supprimant les plus anciens. Cela signifie qu'au fil du temps, des milliers d'instantanés ont été créés et détruits sur chaque système de fichiers. C'est la seule opération en cours au niveau du système de fichiers à laquelle je peux penser avec un effet cumulatif. J'ai essayé de détruire tous les instantanés (mais j'ai maintenu le processus en cours, en en créant de nouveaux) et je n'ai remarqué aucun changement.

Y a-t-il un problème avec la création et la destruction constantes d'instantanés? Je trouve que les avoir est un outil extrêmement précieux, et j'ai été amené à croire qu'ils étaient (à part l'espace disque) plus ou moins gratuits.

Y a-t-il autre chose qui pourrait être à l'origine de ce problème?

EDIT: sortie de commande

Sortie de zpool list:

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

Sortie 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

Ce n'est pas un système très chargé, en général. Les pics sur le graphique ci-dessous sont des sauvegardes nocturnes:

J'ai réussi à rattraper le système lors d'un ralentissement (commençant vers 8 heures ce matin). Certaines opérations sont assez réactives, mais la moyenne de charge est actuellement de 145 et zpool listse bloque simplement. Graphique:

Regardez arc_meta_used et arc_meta_limit. Avec beaucoup de petits fichiers, vous pouvez remplir le cache de métadonnées dans ram afin qu'il doive regarder le disque pour les informations sur les fichiers et peut ralentir le monde à une analyse.

Je ne sais pas comment faire cela sous Linux, mon expérience est sur FreeBSD.