Rallentamenti ZFS estremi dopo diversi mesi

Ho un server generico, che fornisce posta, DNS, web, database e alcuni altri servizi per un numero di utenti.

Ha un Xeon E3-1275 a 3,40 GHz, 16 GB di RAM ECC. Esecuzione del kernel 4.2.3 di Linux, con ZFS-on-Linux 0.6.5.3.

Il layout del disco è 2 unità Seagate ST32000641AS da 2 TB e 1 SSD Samsung 840 Pro da 256 GB

Ho i 2 HD in un mirror RAID-1 e l'SSD si comporta come un dispositivo di cache e log, tutto gestito in ZFS.

Quando ho installato il sistema per la prima volta, è stato incredibilmente veloce. Nessun vero benchmark, solo ... veloce.

Ora noto rallentamenti estremi, specialmente sul filesystem che contiene tutti i maildir. L'esecuzione di un backup notturno richiede oltre 90 minuti per soli 46 GB di posta. A volte, il backup causa un carico così estremo che il sistema non risponde quasi fino a 6 ore.

Ho corso zpool iostat zroot(il mio pool è chiamato zroot) durante questi rallentamenti e ho visto delle scritture dell'ordine di 100-200 kbyte / sec. Non ci sono evidenti errori di I / O, il disco non sembra funzionare particolarmente duramente, ma la lettura è quasi insolitamente lenta.

La cosa strana è che ho avuto la stessa identica esperienza su una macchina diversa, con hardware di specifiche simili, anche se senza SSD, con FreeBSD. Ha funzionato bene per mesi, poi ha rallentato allo stesso modo.

Il mio sospetto è questo: uso zfs-auto-snapshot per creare istantanee a rotazione di ciascun filesystem. Crea istantanee di 15 minuti, orari, giornalieri e mensili e mantiene un certo numero di ciascuna in giro, eliminando la più vecchia. Significa che nel tempo sono state create e distrutte migliaia di istantanee su ciascun filesystem. È l'unica operazione in corso a livello di filesystem che mi viene in mente con un effetto cumulativo. Ho provato a distruggere tutte le istantanee (ma ho mantenuto il processo in esecuzione, creandone di nuove) e non ho notato alcun cambiamento.

C'è un problema con la creazione e la distruzione costante di istantanee? Trovo che abbiano uno strumento estremamente prezioso e sono stato portato a credere che sono (a parte lo spazio su disco) più o meno a costo zero.

C'è qualcos'altro che potrebbe causare questo problema?

EDIT: output del comando

Uscita di zpool list:

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

Uscita di 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

Questo non è un sistema molto impegnato, in generale. I picchi nel grafico seguente sono backup notturni:

Sono riuscito a catturare il sistema durante un rallentamento (a partire dalle 8 di questa mattina). Alcune operazioni sono abbastanza reattive, ma la media del carico è attualmente 145 e si zpool listblocca. Grafico:

Guarda arc_meta_used e arc_meta_limit. Con un sacco di piccoli file puoi riempire la cache dei metadati in ram in modo che debba guardare il disco per le informazioni sui file e può rallentare il mondo a una scansione.

Non sono sicuro di come farlo su Linux, la mia esperienza è su FreeBSD.