A carga do servidor aumenta várias vezes ao dia, a média de carga do mês anterior é 5 vezes a média da carga durante todo o ano

Question

As minhas notificações do Munin configuradas para o nosso cluster LAMP (Debian) têm estado a notificar-me continuamente que a nossa carga na nossa máquina de produção tem estado em níveis perigosos. Embora a carga média anual seja de 2 a 8, a carga no último mês e apenas no mês passado - subiu rapidamente para 10, 18 e, ocasionalmente, até 50-60. Os picos duram apenas 5-10 minutos de cada vez e ocorrem a cada 2-3 horas. Os picos não afetam o desempenho apenas porque eu tenho um script que envia tráfego do nosso servidor para um espelho CDN quando a carga está acima de 10. Eu procurei por tarefas cron que se correlacionam com este período de tempo, mas não há nada que eu possa ver causar isso. O tráfego do site também é normal (recebemos cerca de 200 mil visitas por dia). O banco de dados MySQL com o qual este servidor web se baseia parece estar funcionando normalmente. A carga nesse servidor é baixa e o desempenho é bom.

Eu também estou tentando pensar em qualquer coisa que eu mudei na época em que esse problema começou, e eu realmente não consigo pensar em nada.

Isso provavelmente não é muito para continuar. Talvez exista uma pista na primeira impressão (abaixo) que não estou vendo.

Como faço para encontrar a causa?

Típico superior quando a carga não é spiking:

top - 11:13:09 up 472 days, 25 min,  1 user,  load average: 6.08, 4.29, 3.80
Tasks: 105 total,   1 running, 104 sleeping,   0 stopped,   0 zombie
Cpu(s): 41.2%us,  5.8%sy,  0.0%ni, 49.5%id,  2.7%wa,  0.1%hi,  0.7%si,  0.0%st
Mem:   3369592k total,  2166980k used,  1202612k free,   559504k buffers
Swap:  2650684k total,     1892k used,  2648792k free,  1129116k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
32046 apache    15   0 36300  12m 9828 S   20  0.4   0:01.97 apache2
32679 apache    15   0 36568  13m  10m S   19  0.4   0:01.69 apache2
31441 apache    15   0 36616  13m  10m S   19  0.4   0:04.13 apache2
31477 apache    15   0 36596  13m 9.8m S   15  0.4   0:01.99 apache2
31993 apache    15   0 36876  16m  12m S   12  0.5   0:02.01 apache2
31782 apache    15   0 36836  14m  10m S    8  0.4   0:02.17 apache2
32198 apache    15   0 36536  13m  10m S    7  0.4   0:01.59 apache2
  880 apache    15   0 36508 9708 6236 S    7  0.3   0:00.42 apache2
31945 apache    17   0 36876  16m  13m S    5  0.5   0:03.17 apache2
32197 apache    16   0 36636  10m 7504 S    5  0.3   0:02.70 apache2
32326 apache    15   0 37024  11m 7632 S    5  0.3   0:02.15 apache2
32565 apache    15   0 37280  13m 9.8m S    5  0.4   0:03.75 apache2
32676 apache    15   0 36896  16m  12m S    4  0.5   0:00.95 apache2
32678 apache    15   0 36536  12m 9692 S    4  0.4   0:02.27 apache2
  974 apache    16   0 37064 9888 6016 D    4  0.3   0:00.13 apache2
32150 apache    16   0 36832  13m  10m S    3  0.4   0:01.74 apache2
31780 apache    16   0 36848  11m 7660 S    3  0.3   0:02.87 apache2

E aqui está um top quando estamos a cravar:

top - 15:25:22 up 474 days,  4:37,  1 user,  load average: 78.73, 50.20, 24.79
Tasks: 250 total,   4 running, 244 sleeping,   0 stopped,   2 zombie
Cpu(s): 36.5%us,  4.7%sy,  0.0%ni, 56.4%id,  2.0%wa,  0.1%hi,  0.3%si,  0.0%st
Mem:   3369592k total,  2099904k used,  1269688k free,   553840k buffers
Swap:  2650684k total,     5104k used,  2645580k free,   729252k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
27716 apache    15   0 43612  20m 9.8m S   20  0.6   0:01.95 apache2
16782 apache    16   0 39460  19m  13m R   19  0.6   0:04.61 apache2
19701 apache    15   0 39232  16m  10m S   17  0.5   0:03.18 apache2
19677 apache    16   0 39208  15m 9956 R   12  0.5   0:05.03 apache2
16760 apache    15   0 36620  16m  13m S    8  0.5   0:06.35 apache2
19798 apache    15   0 36564  13m 9988 S    6  0.4   0:02.76 apache2
20325 apache    15   0 36616  13m 9704 S    6  0.4   0:02.11 apache2
19699 apache    15   0 36860  15m  12m S    5  0.5   0:03.10 apache2
15109 apache    15   0 36624  16m  13m S    4  0.5   0:05.97 apache2
15101 apache    15   0 36592  13m  10m S    3  0.4   0:08.96 apache2
15112 apache    15   0 36612  16m  13m S    3  0.5   0:07.57 apache2
20204 apache    15   0 44612  21m 9.9m S    3  0.6   0:03.55 apache2
19624 apache    15   0 36588  13m  10m S    3  0.4   0:02.00 apache2
20151 apache    15   0 36616  16m  13m S    3  0.5   0:02.14 apache2
26252 apache    15   0 37072  13m   9m S    3  0.4   0:01.09 apache2
19805 apache    15   0 36472  16m  12m S    2  0.5   0:03.68 apache2
20163 apache    15   0 36640  13m  10m S    2  0.4   0:02.50 apache2
27260 apache    18   0 44292  20m 9328 S    2  0.6   0:02.08 apache2
29149 apache    15   0 36172  11m 8744 S    2  0.4   0:00.69 apache2
20315 apache    15   0 36360  15m  12m S    2  0.5   0:02.06 apache2
29148 apache    16   0 36184 8872 5644 S    2  0.3   0:00.08 apache2

    

Answer 1

De acordo com o novo sys-admin que veio a bordo, a carga ficou tão alta porque, recentemente, estamos continuamente atingindo a capacidade de nossa alocação de largura de banda (não temos certeza se de entrada ou saída). Alguns respondentes a essa pergunta estão corretos, pois isso não é um sinal de problemas no servidor. É um problema de rede em que novas solicitações devem aguardar a eliminação da largura de banda antes que elas possam prosseguir - por isso, a alta carga (atraso). De qualquer forma, recentemente nos mudamos para um novo datacenter com uma alocação de largura de banda muito maior. Obrigado a todos!

    

Answer 2

O Loadavg não diz muito sobre se o seu sistema está com desempenho insatisfatório; é uma métrica muito geral que descreve o quão ocupado seu sistema é, onde ocupado é definido como um índice do número de processos que estão atualmente sendo executados ou aguardando para executar uma instrução cpu. Em um sistema de oito núcleos, em que a carga de trabalho é descrita por processos de alto volume de curta duração (como, digamos, um servidor da Web), um carregamento acima de 50 pode nem chamar minha atenção.

Você pode correlacionar esses picos com seus registros do apache para ver se os tempos de resposta sofrem durante os períodos de pico? Você está apenas atendendo mais solicitações durante os picos? Você mantém estatísticas sobre coisas como iowait e user vs cpu do sistema, e elas se correlacionam? O outro pôster que mencionou a troca está correto: a troca pode fazer com que os processos se acumulem à medida que o acesso à memória diminui a velocidade do disco, o que pode levar a um carregamento mais alto à medida que os processos permanecem.

Estas são todas as coisas para investigar; mais dados e dados mantidos historicamente podem ajudá-lo a resolver esse problema. Espero que isto ajude; boa sorte!

    

Answer 3

Você está usando algo como o Memcached no back-end? O TTL expira nesse período?

O desempenho é realmente afetado quando a carga ultrapassa 100%? Em CPUs com vários núcleos, isso provavelmente é normal.

P.S também parece que você está mergulhando em sua alocação SWAP; Eu daria uma olhada nisso.

    

Answer 4

Se seus aplicativos Apache estão sendo executados em um back-end de banco de dados, é bem possível que você esteja enfrentando problemas de bloqueio / contenção no lado do banco de dados. Seus processos de apache frequentemente desovados (ou reutilizados) simplesmente se encontram esperando uma requisição de banco de dados de execução longa para ser concluída e, assim, acumulando-se em um número alto.

Portanto, verifique se o seu servidor de banco de dados espelharia a imagem de carregamento. Se acontecer de você usar o MySQL (é o M em LAMP, não é?), Você deve considerar o uso de mysql-snmp para um relatório mais detalhado.