wa (aguardando E / S) do comando top é grande

Tenho um fórum com muitos visitantes. Alguns dias a carga aumenta para chegar a 40 sem aumentar o número de visitantes. Como você pode ver na saída abaixo, o tempo de espera é alto (57%). como encontro a razão disso?
O software para servidor é Apache, MySQL e PHP.

root@server:~# top
top - 13:22:08 up 283 days, 22:06,  1 user,  load average: 13.84, 24.75, 22.79
Tasks: 333 total,   1 running, 331 sleeping,   0 stopped,   1 zombie
Cpu(s): 20.6%us,  7.9%sy,  0.0%ni, 13.4%id, 57.1%wa,  0.1%hi,  0.9%si,  0.0%st
Mem:   4053180k total,  3868680k used,   184500k free,   136380k buffers
Swap:  9936160k total,    12144k used,  9924016k free,  2166552k cached

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   90  3.1   4449:04 mysqld
17422 www-data  20   0  223m  20m  10m S    2  0.5   0:00.21 apache2
17555 www-data  20   0  222m  19m 9968 S    2  0.5   0:00.13 apache2
17264 www-data  20   0  225m  19m 8972 S    1  0.5   0:00.17 apache2
17251 www-data  20   0  220m  12m 4912 S    1  0.3   0:00.12 apache2

.

root@server:~# top
top - 13:39:59 up 283 days, 22:24,  1 user,  load average: 6.66, 10.39, 13.95
Tasks: 318 total,   1 running, 317 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.6%us,  4.2%sy,  0.0%ni, 40.5%id, 40.6%wa,  0.2%hi,  0.8%si,  0.0%st
Mem:   4053180k total,  4010992k used,    42188k free,   119544k buffers
Swap:  9936160k total,    12160k used,  9924000k free,  2290716k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
23930 mysql     20   0  549m 122m 6580 S   44  3.1   4457:30 mysqld
19946 www-data  20   0  223m  21m  10m S    5  0.6   0:00.77 apache2
17316 www-data  20   0  226m  23m  11m S    1  0.6   0:01.76 apache2
17333 www-data  20   0  222m  21m  11m S    1  0.5   0:01.55 apache2
18212 www-data  20   0  225m  22m  11m S    1  0.6   0:01.58 apache2
19528 www-data  20   0  220m  13m 5480 S    1  0.3   0:00.63 apache2
19600 www-data  20   0  224m  20m  11m S    1  0.5   0:00.73 apache2
19942 www-data  20   0  225m  21m  10m S    1  0.5   0:00.82 apache2
20232 www-data  20   0  222m  16m 8760 S    1  0.4   0:00.65 apache2
20243 www-data  20   0  223m  21m  11m S    1  0.5   0:00.57 apache2
20299 www-data  20   0  225m  20m   9m S    1  0.5   0:00.67 apache2
20441 www-data  20   0  225m  21m  10m S    1  0.5   0:00.57 apache2
21201 www-data  20   0  220m  12m 5148 S    1  0.3   0:00.19 apache2
21362 www-data  20   0  220m  12m 5032 S    1  0.3   0:00.17 apache2
21364 www-data  20   0  220m  12m 4916 S    1  0.3   0:00.14 apache2
21366 www-data  20   0  220m  12m 5124 S    1  0.3   0:00.22 apache2
21373 www-data  20   0  222m  14m 7060 S    1  0.4   0:00.26 apache2

Aqui estão algumas ferramentas para encontrar a atividade do disco:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

Em ps auxfvocê também verá quais processos são estão em sono disco uninterpretable ( D), porque eles estão à espera de I / O.

Alguns dias a carga aumenta para chegar a 40 sem aumentar o número de visitantes.

Você também pode criar um backup e ver se o disco rígido está falhando lentamente. Um disco rígido geralmente começa a desacelerar antes de morrer. Isso também pode explicar a alta carga.

A saída da parte superior sugere que o DBMS está enfrentando a maioria das esperas de E / S, portanto, os problemas de ajuste do banco de dados são um candidato óbvio para investigar.

A E / S aguardando em um servidor de banco de dados - particularmente em picos de carga - é uma pista de que seu DBMS pode estar ligado ao disco (ou seja, você precisa de um subsistema de disco mais rápido) ou pode ter um problema de ajuste. Você provavelmente também deve analisar o perfil do servidor de banco de dados - ou seja, obter um rastro do que está fazendo e quais consultas estão demorando.

Alguns pontos de partida para diagnosticar problemas de ajuste do banco de dados: -

• Encontre as consultas que demoram mais tempo e veja os planos de consulta. Veja se algum tem planos de consulta ímpares, como uma verificação de tabela, onde não deveria estar. Talvez o banco de dados precise de um índice adicionado.

• Tempos de espera longos de recursos podem significar que alguns dos principais pools de recursos precisam ser expandidos.

• Longos tempos de espera de E / S podem significar que você precisa de um subsistema de disco mais rápido.

• Seus volumes de log e dados estão em unidades separadas? Os logs do banco de dados têm muitas gravações sequenciais pequenas (essencialmente, elas se comportam como um buffer de anel). Se você tiver uma carga de trabalho de acesso aleatório ocupado compartilhando os mesmos discos que seus logs, isso afetará proporcionalmente a taxa de transferência do log. Para que uma transação do banco de dados confirme, as entradas de log devem ser gravadas no disco, para que isso coloque um gargalo em todo o sistema.
  
  Observe que alguns mecanismos de armazenamento MySQL não usam logs, portanto isso pode não ser um problema no seu caso.

Nota de rodapé: Sistemas de filas

Os sistemas de enfileiramento (um modelo estatístico para taxa de transferência) ficam hiperbolicamente mais lentos à medida que o sistema se aproxima da saturação. Para uma aproximação de alto nível, um sistema que é 50% saturado tem um comprimento médio de fila de 2. Um sistema que é 90% saturado tem um comprimento de fila 10, um sistema que é 99% saturado tem um comprimento de fila de 100.

Portanto, em um sistema próximo à saturação, pequenas alterações na carga podem resultar em grandes alterações nos tempos de espera, neste caso, manifestando-se como o tempo gasto aguardando na E / S. Se a capacidade de E / S do seu subsistema de disco estiver quase saturada, pequenas alterações na carga poderão resultar em alterações significativas nos tempos de resposta.

Execute iotopou atop -dDpara ver o que os processos estão fazendo. Use stracese você precisar de um olhar mais atento.

Nas duas telas, com certeza parece que "mysqld" é responsável.

Você precisa ver o que esse daemon está fazendo ... quais consultas estão sendo executadas.

Alguns dias a carga aumenta para chegar a 40 sem aumentar o número de visitantes.

O que os usuários estão fazendo pode ser tão significativo quanto o número que está realmente lá. Operações como pesquisar no fórum serão mais exigentes do que apenas carregar e visualizar threads individuais ou listas de threads.

Além disso: você está executando em um servidor dedicado ou em um VPS? Se o seu serviço não estiver em um servidor dedicado, as ações dos aplicativos em execução no mesmo host terão efeito, pois as VMs com as quais sua VM compartilha um host competirão por um compartilhamento do recurso de E / S.

Como outros já apontaram, ferramentas como iotopo ajudarão a analisar mais profundamente quais tarefas estão aguardando respostas de E / S e quais arquivos eles estão acessando no momento.

Como Flip diz, parece que o problema está relacionado ao que o mysql está fazendo.

Atualmente, cerca de metade da sua memória física está sendo usada para armazenamento em cache de E / S - o software do fórum geralmente gera muitas consultas rápidas retornando um pequeno número de linhas, com áreas quentes altamente distorcidas do disco - então há algo definitivamente errado se o sistema estiver gastando tanto tempo de espera.

Eu só vejo o uso da CPU / disco assim ao executar consultas que atualizam milhões de linhas.

A alta média de carga é conseqüência direta da E / S.

Aumente o registro do seu mysql para ver se há código incorreto / alterar índices ajudaria. Analisar suas tabelas pode ajudar (mas provavelmente não muito).

C.