☰

服务器因“巨大任务超时”而崩溃

tag-icon • tag-icon mysql debian kernel-panic
服务器因“巨大任务超时”而崩溃

首先，我已经阅读了很多有关“巨大任务超时”内核恐慌的文章，并且知道如果服务器资源不足，通常会​​发生这种情况。

出现的错误信息仅有的在 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 和其他一些较小的东西。它主要托管一个网站和一个包含约 25 GB 数据的大型 MySQL 数据库。

磁盘使用率约为12%。

我安装了 Munin 进行监控，没有发现任何异常。但自从上次崩溃以来，我也安装了它，sysstat但我真的不知道哪些日志文件对您有用。所以请请求您认为需要的那个。

事故发生于 2015 年 10 月 3 日 17:37 GMT 左右。

我认为这与 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，使其可以使用总 RAM 的大约 80%。MySQL 服务器的平均执行速度为每秒 2k 次查询，读取/写入比例为 50/50。

在崩溃之前，我看到htop24 GB 中大约有 21 GB 被使用，1.5 GB 交换空间中大约有 500 MB 被使用，CPU 使用率正常。

编辑： 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

编辑：

Munin 图片

https://i.stack.imgur.com/hOK7w.jpg

MySQL 查询

编辑：

我联系了我的 ISP，他们说崩溃时没有发生任何异常。所以这与我的设置有关。现在我将检查如果我将 减少innodb_buffer_pool_size到 14 GB 并添加会发生什么innodb_flush_method = O_DIRECT。

答案1

问题不是内核崩溃。您在控制台上看到的是内核调用中挂起的进程。

您应该检查控制台或 /var/log/syslog 或 /var/log/messages，并搜索内核记录的完整堆栈跟踪。您将知道哪个子系统运行缓慢。可能是 @Belmin Fernandez 提到的磁盘，也可能是网络...

现在您还必须从主机获取一些统计数据。如果 CPU 使用率或磁盘 I/O 过载，则可能由同一主机上运行的其他虚拟机导致资源匮乏。很难确定这是否是仅由虚拟机导致的原因。

KVM 支持半虚拟化驱动程序。请向 ISP 确认主机上运行的所有虚拟机上是否都安装了这些驱动程序并且是最新的。

如果您在同一台机器上同时运行 MySQL 和 Nginx，请确保 MySQL 和 Nginex 可以将所有活动数据保存在 RAM 中。分配给 MySQL 的 80% 可能太高了。

您能否发布 Munin 文件系统缓存图表。当 FS 缓存越来越低时，您的虚拟机就会内存不足。

如果你有控制台访问权限，那么你就可以使用内核的魔法系统请求键来触发任务列表。启用它echo 1 > /proc/sys/kernel/sysrq，然后您可以使用控制台列出正在运行的任务：ALT++SysRqt

相关内容