O servidor trava com o “enorme tempo limite da tarefa”

Question

Primeiro de tudo, eu li muito sobre o pânico do kernel "timeout enorme tarefa" e sei que isso acontece frequentemente se o servidor está sem recursos.

Mensagens de erro que aparecem apenas no console do VNC e não em nenhum arquivo de log:

[264240.505133] "echo 0 > /proc/sys/kernel/huge_task_timeout_secs" disables this message.
[264240.505359] INFO: task nginx:2333 blocked for more than 120 secounds.
[264240.505454] "echo 0 > /proc/sys/kernel/huge_task_timeout_secs" disables this message.
[264240.505658] INFO: task nginx:2334 blocked for more than 120 secounds.
[264240.505752] "echo 0 > /proc/sys/kernel/huge_task_timeout_secs" disables this message.
[264240.505946] INFO: task nginx:2335 blocked for more than 120 secounds.
[264240.506038] "echo 0 > /proc/sys/kernel/huge_task_timeout_secs" disables this message.
[264240.506251] INFO: task php5-fpm:2415 blocked for more than 120 secounds.
...

Especificações do servidor :

8 Core Intel® Xeon® E5-2660V3
24 GB DDR4
320GB SSD

A máquina é virtualizada pelo KVM. Ele executa debian wheezy com PHP5-FPM, NGINX, MySQL e algumas outras coisas menores. Principalmente ele hospeda um WebSite e um enorme banco de dados MySQL com cerca de 25 GB de dados.

O uso de disco é de cerca de 12%.

Eu instalei o Munin para monitoramento, o que não mostra nenhuma anomalia. Mas desde a última batida que eu instalei também sysstat , mas eu realmente não sei qual dos arquivos de log pode ser útil para você. Então, por favor, solicite aquele que você acha necessário.

O acidente aconteceu por volta de 10.03.2015 17:37 GMT.

Na minha opinião, isso tem algo a ver com o MySQL. Aqui o my.cnf

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
lc-messages-dir = /usr/share/mysql
skip-external-locking

bind-address        = 127.0.0.1

key_buffer      = 16M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 8
myisam-recover-options  = BACKUP
max_connections         = 50
query_cache_limit   = 1M
query_cache_size        = 16M

log_error = /var/log/mysql/error.log

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log

expire_logs_days    = 10
max_binlog_size         = 100M

innodb_buffer_pool_size = 18G
innodb_log_file_size    = 256M

[mysqldump]
quick
quote-names
max_allowed_packet  = 16M

[mysql]

[isamchk]
key_buffer      = 16M

!includedir /etc/mysql/conf.d/

Como você pode ver, configurei o MySQL que ele pode usar cerca de 80% do total de RAM. O servidor MySQL realiza em média 2k consultas / secound com 50/50 leitura / gravação.

Logo antes da falha eu vi em htop que cerca de 21 GB de 24 GB são usados e 500 MB de 1,5 GB de swap, o uso da CPU era normal.

EDITAR: sar -u do tempo direto antes do acidente:

18:27:01        CPU     %user     %nice   %system   %iowait    %steal     %idle
18:29:01        all      8,28      0,00      1,31      5,61      0,02     84,77
18:31:01        all      7,65      0,41      1,41      5,73      0,03     84,78
18:33:01        all      7,95      0,00      1,25      5,51      0,02     85,27
18:35:01        all      8,87      0,00      1,42      5,53      0,03     84,15
18:37:01        all      8,99      0,42      1,40      5,94      0,03     83,22
Average:        all      8,65      0,16      1,35      5,08      0,03     84,73

EDITAR:

Imagens do Munin

link

Consulta ao MySQL

EDITAR:

Contactei o meu ISP e eles disseram que nada anormal aconteceu no momento da falha. Então, tem algo a ver com a minha configuração. Agora vou verificar o que acontece se eu reduzir o innodb_buffer_pool_size para 14 GB e adicionar o innodb_flush_method = O_DIRECT .

    

Answer 1

O problema não é um pânico do kernel. O que você vê no console é o processo interrompido em uma chamada do kernel.

Você deve verificar o console ou o / var / log / syslog ou / var / log / messages e procurar pelo rastreamento de pilha completo que é registrado pelo kernel. Você terá uma idéia de qual subsistema é lento. Poderia ser disco como mencionado por @Belmin Fernandez, poderia ser rede ...

Agora você também precisa obter algumas estatísticas do host. Se o uso da CPU ou a E / S do disco for supercomprometido, você poderá ter uma privação de recursos causada por outras VMs em execução no mesmo host. Será difícil determinar se essa é a causa apenas da VM.

O KVM tem suporte para drivers de paravirtualização. Verifique com o ISP se eles estão instalados e atualizados em todas as VMs em execução na máquina host.

Se você executar o MySQL e o Nginx na mesma máquina, certifique-se de que o MySQL e o Nginex possam manter todos os dados ativos na RAM. 80% alocado para o MySQL pode ser alto.

Poderia, por favor, publicar gráficos Munin do Cache do Sistema de Arquivos. Quando o FS Cache está ficando cada vez mais baixo, sua VM está com fome de memória.

Se você tiver acesso ao console, você pode usar a chave SysRq mágica do kernel para acionar uma lista de tarefas. Habilite echo 1 > /proc/sys/kernel/sysrq , então você pode usar o console para listar as tarefas em execução: ALT + SysRq + t