Determine o que está causando alta E / S de disco

Question

Eu tenho um problema com o meu VPS e disco I / O. Meu servidor está executando o nginx + PHP-FPM + APC. O banco de dados está localizado em outro VPS dedicado. Eu tenho vários sites WordPress MU que vivem no servidor web. A taxa média de E / S é de 6k / segundo.

Estou tentando entender o que está causando a alta E / S.

Saída de 'free -m':

            total   used   free   shared   buffers   cached
Mem:         1005    973     31        0        96      568
-/+ buffers/cache:   307    697
Swap:         255      8    247

Saída do 'iotop':

Total DISK READ: 0.00 B/s | Total DISK WRITE: 3.90 M/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2150 be/4 root        0.00 B/s    0.00 B/s  0.00 % 65.25 % [flush-202:0]
 6694 be/4 www-data    0.00 B/s   19.64 K/s  0.00 %  0.00 % php-fpm: pool www
 6700 be/4 www-data    0.00 B/s   23.56 K/s  0.00 %  0.00 % php-fpm: pool www
 8646 be/4 www-data    0.00 B/s  424.12 K/s  0.00 %  0.00 % php-fpm: pool www
10974 be/4 www-data    0.00 B/s   19.64 K/s  0.00 %  0.00 % php-fpm: pool www

O processo 'flush-202: 0' às vezes atinge E / S de 99%. Eu li este é o processo de liberação de cache de disco, mas o que faz com que ele seja executado e como faço para corrigi-lo?

    

Answer 1

Não tenho certeza se a amostra iotop mostra algo incomum. Não é um problema para o processo de flush ter uma alta porcentagem de sua E / S a qualquer momento se não houver muita E / S acontecendo naquele momento.

Eu instalaria o no topo , que pode apresentar dados em tempo real como o iotop, mas tem a vantagem de também registrar amostras em todo o processo. o dia. Um dia depois de instalá-lo, eu abriria os dados registrados com atop -r log_filename , depois passaria pelas amostras com t até que descobrisse quando a E / S reportada na saída do nível do sistema é alta. Então eu mudaria a saída por processo para o disco com d para ver quais processos estavam gerando a atividade de E / S.

    

Answer 2

Isso pode ser um problema com a APC.

Se funcionar para você, na sua configuração do PHP, defina:

apc.mmap_file_mask = /tmp/apc.shm.XXXXXX

Se isso não funcionar, remova completamente a configuração apc.mmap_file_mask.

Se não for APC, então é outra coisa que usa cache em disco. Como a memória virtual, por exemplo, ou um cache de verniz, ou talvez algo que use arquivos DBM. Existem muitas possibilidades lá. Talvez até mesmo um mecanismo de banco de dados.

Os usuários da APC provavelmente devem agora migrar para o opcache do Zend, que vem com distribuições gratuitas posteriores do PHP (e versões anteriores pagas, como eu me lembro). Observar o ajuste do opcache ainda pode ser significativo para gerenciar seu carregamento de E / S. O link é uma introdução útil e vincula-se a várias ferramentas que podem ser usadas para verificar o desempenho do cache (especialmente a taxa de acertos). ).

    

Answer 3

Você pode conseguir isso com o programa pidstat. Algumas distribuições não vêm com ele instalado. Mas você pode baixar o pacote sysstate de aqui e compilá-lo. Não o instale, mas copie o pidstat que ele compila (ou simplesmente execute-o no diretório atual). Você pode passar o sinalizador '-d' para obter a saída desejada.