Como determinar o que está causando a média de carga do meu servidor para ir para 90

Question

Tudo bem, estou completamente perdido aqui. Eu tenho esse servidor Ubuntu em execução há cerca de três anos. Nos últimos dois meses, ele começou a se comportar de forma estranha e está piorando. É um servidor bastante ocupado rodando cerca de 15 sites e uma série de outras ferramentas nele. É típico de carga média de 15min é 0,3. No entanto, o seu 'foi spiking para cerca de 90 a cada 12 horas ou mais.

Tenho certeza de que isso tem algo a ver com o mysql e o servidor de alguma forma sendo bloqueado e o apache apenas esperando que as coisas sejam abertas. Aqui está um top quando as coisas estão enlouquecendo.

Tasks: 143 total,  20 running, 123 sleeping,   0 stopped,   0 zombie
Cpu(s): 34.3%us, 62.9%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.2%hi,  2.6%si,  0.0%st
Mem:   2061444k total,   911460k used,  1149984k free,    11156k buffers
Swap:  1421712k total,        0k used,  1421712k free,   126728k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1080 mysql     20   0  397m  59m 5892 S   18  3.0   0:37.37 mysqld
 1602 www-data  20   0  198m  26m 4948 R    7  1.3   0:08.17 apache2
 1725 www-data  20   0  189m  24m  11m R    7  1.2   0:04.33 apache2
 1719 www-data  20   0  189m  25m  12m R    7  1.2   0:03.88 apache2
 1802 www-data  20   0  192m  20m 4808 S    7  1.0   0:03.15 apache2
 1521 www-data  20   0  199m  28m 6912 R    6  1.4   0:10.15 apache2
 1530 www-data  20   0  193m  22m 5104 S    5  1.1   0:06.53 apache2
 1536 www-data  20   0  196m  25m 4936 R    5  1.2   0:07.93 apache2
 1583 www-data  20   0  186m  21m  11m R    5  1.0   0:03.46 apache2
 1722 www-data  20   0  193m  21m 4956 R    5  1.1   0:04.91 apache2
 1906 www-data  20   0  182m  12m 6724 S    5  0.6   0:00.61 apache2
 1439 root      20   0 92040 3672 2280 S    5  0.2   0:08.04 ezproxy
 1539 www-data  20   0  194m  27m 9548 R    4  1.3   0:08.08 apache2
 1716 www-data  20   0  187m  22m  11m R    4  1.1   0:03.36 apache2
 1891 www-data  20   0  183m  18m  11m S    4  0.9   0:00.61 apache2
 1498 www-data  20   0  194m  23m 6264 S    4  1.2   0:11.47 apache2
 1517 www-data  20   0  193m  22m 5212 R    4  1.1   0:06.56 apache2
 1523 www-data  20   0  190m  26m  12m S    3  1.3   0:07.61 apache2
 1761 www-data  20   0  186m  20m  10m R    2  1.0   0:02.66 apache2
 1779 www-data  20   0  184m  19m  10m R    2  0.9   0:02.69 apache2
 1711 www-data  20   0  185m  20m  11m R    2  1.0   0:03.32 apache2
 1728 www-data  20   0  182m  11m 5028 R    2  0.6   0:01.14 apache2
 1819 www-data  20   0  181m 8120 3332 S    2  0.4   0:00.49 apache2
 1886 www-data  20   0  182m  11m 6364 S    2  0.6   0:01.18 apache2
 1899 www-data  20   0  184m  18m  10m S    2  0.9   0:01.38 apache2
 1497 www-data  20   0  191m  27m  12m S    1  1.4   0:07.84 apache2
 1766 www-data  20   0  181m  10m 5016 R    1  0.5   0:01.39 apache2
 1871 www-data  20   0  184m  19m  11m R    1  1.0   0:00.98 apache2
 1563 www-data  20   0  186m  23m  13m S    1  1.2   0:07.37 apache2
 1865 www-data  20   0  184m  18m  10m S    1  0.9   0:01.56 apache2
 1494 www-data  20   0  193m  25m 8352 S    1  1.3   0:12.07 apache2
 1512 www-data  20   0  186m  23m  13m R    1  1.1   0:06.10 apache2
 1526 www-data  20   0  186m  24m  13m R    1  1.2   0:06.30 apache2
 1816 www-data  20   0  184m  18m  10m S    1  0.9   0:01.60 apache2
 1516 www-data  20   0  184m  19m  11m S    1  1.0   0:04.12 apache2

Neste momento, as coisas estão correndo com calma,

Uptime: 241264  Threads: 1  Questions: 1870412  Slow queries: 1354  Opens: 13818  Flush tables: 1  Open tables: 256  Queries per second avg: 7.752

Aqui estão todos os meus tamanhos de banco de dados em MB

name1   14.78335094
name2   11.08541870
name3   31.01449203
name4   6.24377346
name5   0.36655807
name6   10.95312500
information_schema  0.00781250
mysql   0.60296535
name7   2.19595051
name8   1.82343006
name9   20.51372623
name0   59.42693043

Eu verifiquei o log de consultas lentas, mas quando o bloqueio acontece, todas as consultas são colocadas no log de consultas lentas. Eu não tenho estado no servidor quando acontece para executar um proccesslist. Há mais alguma coisa que eu possa fazer além disso?

Atualização: Aqui está a saída do script tuning-primer.sh: link

Atualização: aqui está um IOStat durante um freakout:

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda               5.25         6.05       106.35    3090763   54314928

E um vmstat 3: link

Agora com mais SAR! link

Obrigado pela ajuda.

    

Answer 1

Tente instalar sar e executá-lo em segundo plano. Você pode ter uma carga de disco que está aumentando. sar permitirá que você veja quais recursos têm as cargas mais pesadas quando as coisas dão errado assim.

Você alta sys load pode indicar que você tem muita E / S acontecendo. Isso pode ser um resultado do crescimento natural do banco de dados. Você possui um processo de arquivamento para remover dados antigos dos bancos de dados? Se não, você chegará a um ponto em que os dados necessários para as varreduras de tabela não caberão mais na memória. Quando isso acontece, o desempenho vai subitamente e significativamente. O log de consultas lentas pode incluir algumas consultas que podem ser aprimoradas pela adição de um índice.

Se você tiver outro sistema com o qual você pode executar munin , convém instalar munin-node no servidor. Isso fornecerá a saída gráfica de alguns dos dados disponíveis em sar . Verifique os gráficos de tempos em tempos para ver se as coisas estão mudando.

EDIT: Parece que você pode ter um vazamento de memória em algum código em execução no apache. Tente definir MaxRequestsPerChild para cerca de 100 e reiniciar o apache. Se isso resolver seu problema, tente encontrar seu vazamento de memória.

    

Answer 2

O tamanho do seu banco de dados está em MB, certo? Isso é bastante pequeno e deve ficar quase completamente na quantidade de memória configurada, então eu não acho que o mysql é o problema aqui. Você poderia postar a saída do MySQL Tuning Primer ? Além disso, você deve definitivamente algo como munin / cacti / .. para representar graficamente e coletar dados sobre o seu sistema. Que tipo de software está executando suas máquinas? coisas php? Você já está usando um cache de opcode como o APC?

    

Answer 3

É possível que os dados tenham crescido em tamanho a ponto de uma consulta periódica do MySQL ter iniciado o retorno / processamento de tantos resultados que o MySQL está ficando sem memória física e tendo que utilizar grandes quantidades de memória virtual?

    

Answer 4

Abre: 13818 Mesas abertas: 256

... todas as tabelas estão abertas no disco, mas 256 delas. O disco é lento e bloqueador.

Você pode tentar aumentar o valor table_cache do mysql em /etc/mysql/my.cnf

Também execute:

mysqlcheck --auto-repair --check --optimize --all-databases

Para recuperar algo do desempenho original.

De qualquer forma, 2G de RAM, para 26 milhões de processos httpd, dão espaço para não mais que +/- 80 processos httpd ... dizem que muitas webs têm entre 50 e 100 "arquivos" (js, css, imgs, etc) ao servidor para cada solicitação ... então, trocar e bloquear é fácil com algumas visitas.

    

Answer 5

Além da ferramenta sar , você também pode usar as ferramentas vmstat e iostat . iostat irá ajudá-lo se o problema for relacionado a IO. Talvez possamos ajudá-lo melhor se você nos der a saída de, e. %código%. (Isso imprimirá a saída do vmstat a cada 3 segundos. Você pode parar a ferramenta depois de um minuto ou dois.)