Eu tenho um servidor de propósito geral, fornecendo email, DNS, web, bancos de dados e alguns outros serviços para vários usuários.
Tem um Xeon E3-1275 a 3.40 GHz, 16 GB de RAM ECC. Executando o kernel Linux 4.2.3, com o ZFS-on-Linux 0.6.5.3.
O layout do disco é de 2 unidades Seagate ST32000641AS 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á agindo como um dispositivo de cache e log, tudo gerenciado no ZFS.
Quando eu configurei o sistema pela primeira vez, foi incrivelmente rápido. Sem referências reais, apenas ... rápido.
Agora, percebo lentidão extrema, especialmente no sistema de arquivos que contém todos os maildirs. Fazer um backup noturno leva mais de 90 minutos por meros 46 GB de e-mail. Às vezes, o backup causa uma carga tão extrema que o sistema quase não responde por até 6 horas.
Eu corri zpool iostat zroot (meu pool recebeu o nome zroot ) durante essas lentidões e as gravações foram exibidas na ordem de 100-200kbytes / s. Não há erros óbvios de E / S, o disco não parece estar funcionando particularmente, mas a leitura é quase inutilmente lenta.
O mais estranho é que eu tive exatamente a mesma experiência em uma máquina diferente, com hardware de especificação similar, embora sem SSD, rodando o FreeBSD. Funcionou bem durante meses, depois ficou lento da mesma forma.
Minha suspeita é a seguinte: eu uso zfs-auto-snapshot para criar instantâneos contínuos de cada sistema de arquivos. Ele cria instantâneos de 15 minutos, de hora em hora, diários e mensais e mantém um certo número de cada um deles, excluindo os mais antigos. Isso significa que, com o tempo, milhares de instantâneos foram criados e destruídos em cada sistema de arquivos. É a única operação contínua em nível de sistema de arquivos que eu posso imaginar com um efeito cumulativo. Eu tentei destruir todos os instantâneos (mas mantive o processo em execução, criando novos), e não notei nenhuma mudança.
Existe um problema em constantemente criar e destruir instantâneos? Eu acho que eles têm uma ferramenta extremamente valiosa e foram levados a acreditar que eles são (além do espaço em disco) mais ou menos custo zero.
Existe algo mais que possa estar causando esse problema?
EDIT: saída de 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:
Euconseguipegarosistemaduranteumadesaceleração(começandoporvoltadas8horasdamanhã).Algumasoperaçõessãobastanteresponsivas,masamédiadecargaéatualmentede145,ezpoollistapenastrava.Gráfico:
Veja arc_meta_used e arc_meta_limit. Com muitos arquivos pequenos, você pode preencher o cache de meta-dados no RAM, de modo que ele precisa examinar o disco para obter informações sobre o arquivo e atrasar o mundo.
Não sei como fazer isso no Linux, minha experiência é no FreeBSD.