E / S de disco alta quando o cache é usado?

Alguns dias atrás, notei uma espera de E / S no disco e uma queda na atividade do disco (o que foi ótimo). Então também noto que meu cache estava cheio (*) e fragmentado. Então eu limpei o cache. Depois disso, a latência e a atividade do disco saltaram para o nível anterior (o que era ruim).

O IOtop mostra que [jbd2 / sda2-8] e [flush-8: 00] estão sempre em cima do uso do disco. Este é um Dell R210, hardware RAID 1 (H200) com muita memória livre (16 GB no total, dos quais cerca de 8 GB são de buffer / cache).

(*) O cache é o cache do código de operação da APC para PHP, o que reduz o acesso ao disco para execução de scripts PHP. O cache estava cheio e fragmentado porque incluía arquivos da instância de desenvolvimento. Quando notei isso, eu os filtrava.

A questão é: por que a E / S do disco aumenta quando teoricamente deve diminuir? Abaixo estão alguns gráficos de munin. O cache estava cheio de 6 a 8 de fevereiro.

Alterar depois que eu comentei o apc.mmap_file_mask conforme informado por @ cyberx86

E depois de alguns dias https://serverfault.com/a/362152/88934

Se você usar o mapeamento de memória suportada por arquivo (por exemplo apc.mmap_file_mask=/tmp/apc.XXXXXX), poderá ver E / S elevada.

Tente configurar apc.mmap_file_maskpara usar memória compartilhada (por exemplo /apc.shm.XXXXXX) ou para /dev/zero(memória mmapped anônima). Manter a configuração indefinida usa como padrão a memória mmapped anônima.

Normalmente, os arquivos mmapped são ótimos:

• Comparado a armazenar algo totalmente na memória, os arquivos mmapped geralmente requerem menos memória
• Comparado a salvar algo em um arquivo, os arquivos mmapped requerem menos E / S de disco (já que as gravações podem ser agregadas).

No entanto, em comparação com o armazenamento de algo puramente na memória, eles incluem E / S adicional - consideravelmente quando o arquivo está sendo alterado continuamente. A desvantagem de não usar arquivos mmappedados é a falta de persistência - seu cache não sobreviverá a uma reinicialização, pois é armazenado apenas na memória.

Pode-se sugerir, portanto, que, enquanto o cache estava sendo preenchido e estabilizado, ele estava sofrendo a maior parte das alterações, que precisavam ser constantemente gravadas no disco; quando o cache estava cheio, o ttl de cada objeto diminuía a taxa de entrega dos dados no cache, diminuindo as alterações e reduzindo as gravações em disco.

Depois de alguns dias, agora quero voltar com alguns gráficos. A mudança melhora muito essa situação. Reduz tudo, exceto o tempo de serviço de IO (acho que é porque não há mais leitura de arquivos PHP trivial e barata).

A carga do servidor (já era bastante baixa, então eu não havia descoberto a alteração).