Сервер вылетает из-за «огромного таймаута задачи»

Перво-наперво, я много читал о панике ядра "огромный тайм-аут задачи" и знаю, что это часто происходит, если на сервере не хватает ресурсов.

Сообщения об ошибках, которые появляются только в консоли VNC нет ни в одном файле журнала:

[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.
...

Характеристики сервера:

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

Машина виртуализирована KVM. Он запускает debian wheezy с PHP5-FPM, NGINX, MySQL и некоторыми другими более мелкими вещами. В основном на нем размещается веб-сайт и огромная база данных MySQL с данными размером около 25 ГБ.

Использование диска составляет около 12%.

Я установил Munin для мониторинга, который не показывает аномалий. Но с момента последнего сбоя я также установил sysstat но я действительно не знаю, какие файлы журналов могут быть вам полезны. Пожалуйста, попросите тот, который, по вашему мнению, нужен.

Катастрофа произошла примерно 10.03.2015 17:37 мск.

На мой взгляд, это как-то связано с MySQL. Здесь 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/

Как видите, я настроил MySQL так, что он может использовать около 80% общей оперативной памяти. Сервер MySQL выполняет в среднем 2k запросов в секунду при чтении / записи 50/50.

Прямо перед катастрофой я увидел htop что используется около 21 ГБ из 24 ГБ и 500 МБ из 1,5 ГБ подкачки, использование ЦП было нормальным.

РЕДАКТИРОВАТЬ: sar -u времени непосредственно перед аварией:

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

РЕДАКТИРОВАТЬ:

Мунин изображения

http://imgur.com/a/0BZa0

MySQL запрос

РЕДАКТИРОВАТЬ:

Я связался со своим интернет-провайдером, и они сказали, что во время сбоя не произошло ничего необычного. Так что это как-то связано с моей настройкой. Сейчас проверю, что будет, если я уменьшу innodb_buffer_pool_size до 14 ГБ и добавить innodb_flush_method = O_DIRECT.