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

Question

Há alguns dias, notei uma espera de E / S de disco e queda de atividade de disco (o que foi ótimo). Então, também noto que meu cache estava cheio (*) e fragmentado. Então eu corri cache. Depois disso, a latência do disco 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 no topo 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 opcode da APC para PHP, o que reduz o acesso ao disco para execução de script PHP. O cache estava cheio e fragmentado porque incluía arquivos da instância de desenvolvimento. Quando notei isso, eu os filtrei.

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

Alteredepoisqueeucomenteiapc.mmap_file_maskcomoditopor@cyberx86

Depoisdealgunsdias, link

    

Answer 1

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

Tente definir apc.mmap_file_mask para usar memória compartilhada (por exemplo, /apc.shm.XXXXXX ) ou para /dev/zero (memória mmapped anônima). Manter a configuração indefinida é padronizado usando memória mmap anônima.

Geralmente, os arquivos mmap são ótimos:

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

No entanto, em comparação ao armazenamento de algo puramente na memória, eles incorrem em E / S adicionais - consideravelmente, portanto, quando o arquivo está em constante mudança. A desvantagem de não usar arquivos mmap é a falta de persistência - seu cache não sobreviverá a um reinício, já que ele é armazenado apenas na memória.

Pode-se sugerir, portanto, que enquanto o cache estava sendo preenchido e estabilizado, ele passava pela maioria das alterações, que tinham que ser constantemente gravadas em disco; uma vez que o cache estava cheio, o ttl de cada objeto diminuía a taxa de transferência de dados no cache, diminuindo a mudança e reduzindo as gravações de disco.

    

Answer 2

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

A carga do servidor (já estava bem baixa, então eu não havia descoberto a mudança).