Lentidão extrema no ZFS após vários meses

Eu tenho um servidor de uso geral, fornecendo correio, DNS, web, bancos de dados e alguns outros serviços para vários usuários.

Ele possui um Xeon E3-1275 a 3,40 GHz e 16 GB de RAM ECC. Executando o kernel do Linux 4.2.3, com o ZFS no Linux 0.6.5.3.

O layout do disco é de duas unidades Seagate ST32000641AS de 2 TB e 1x SSD Samsung 840 Pro de 256 GB

Eu tenho os 2 HDs em um espelho RAID-1 e o SSD está atuando como um dispositivo de cache e log, todos gerenciados no ZFS.

Quando eu configurei o sistema, ele foi incrivelmente rápido. Não há benchmarks reais, apenas ... rápido.

Agora, noto lentidões extremas, especialmente no sistema de arquivos que contém todas as maildirs. Fazer um backup noturno leva mais de 90 minutos para apenas 46 GB de correio. Às vezes, o backup causa uma carga tão extrema que o sistema quase não responde por até 6 horas.

Corri zpool iostat zroot(meu pool é nomeado zroot) durante essas lentidões e vi gravações da ordem de 100-200kbytes / s. Não há erros óbvios de IO, o disco não parece estar funcionando particularmente, mas a leitura é quase inusoravelmente lenta.

O estranho é que eu tive exatamente a mesma experiência em uma máquina diferente, com hardware de especificação semelhante, embora sem SSD, executando o FreeBSD. Funcionou bem por meses e depois ficou lento da mesma maneira.

Minha principal suspeita é a seguinte: uso o zfs-auto-snapshot para criar snapshots contínuos de cada sistema de arquivos. Ele cria instantâneos de 15 minutos, por hora, diariamente e mensalmente e mantém um certo número de cada um deles, excluindo os mais antigos. Isso significa que, com o tempo, milhares de snapshots foram criados e destruídos em cada sistema de arquivos. É a única operação em andamento no nível do sistema de arquivos em que consigo pensar com um efeito cumulativo. Tentei destruir todos os instantâneos (mas mantive o processo em execução, criando novos) e não notei nenhuma alteração.

Existe um problema com a constante criação e destruição de instantâneos? Acho que tê-los uma ferramenta extremamente valiosa e fui levado a acreditar que eles são (além do espaço em disco) mais ou menos com custo zero.

Há algo mais que possa estar causando esse problema?

EDIT: saída do comando

Saída de zpool list:

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

Saída 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 não é um sistema muito ocupado, em geral. Os picos no gráfico abaixo são backups noturnos:

Consegui capturar o sistema durante uma desaceleração (a partir das 8 horas da manhã). Algumas operações são bastante responsivas, mas a média de carga atualmente é 145 e zpool listapenas trava. Gráfico:

Veja arc_meta_used e arc_meta_limit. Com muitos arquivos pequenos, você pode preencher o cache de metadados no RAM, para que ele tenha que procurar informações no arquivo e pode atrasar o mundo.

Não sei como fazer isso no Linux, minha experiência é no FreeBSD.