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
.