☰

高负载会导致服务器挂起并出现错误“阻塞超过 120 秒”吗？

tag-icon • tag-icon linux kernel
高负载会导致服务器挂起并出现错误“阻塞超过 120 秒”吗？

目前正在运行几个 VM 和“裸机”服务器。Java 运行速度很快 - 有时超过 400%。服务器随机挂起，控制台中出现错误“java - 阻塞时间超过 120 秒”- kjournald 等。

我无法获得 dmesg 输出，因为由于某种原因，此错误仅写入控制台，而由于这是远程托管的，我无法访问控制台。因此，我无法复制完整的跟踪。

我改变了此环境 - 甚至是物理服务器，但它仍然在发生。

我将 hung_task_timeout_secs 更改为 0，以防这是误报http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html。

另外，irqbalance 尚未安装，也许它会有帮助？

这是 Ubuntu 10.04 64 位 - 与最新的 2.6.38-15-server 和 2.6.36 有同样的问题。

CPU 或内存问题/没有剩余交换会导致这个问题吗？

这是控制台消息：

[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.

答案1

是的，可以。

这句话的意思非常明确：内核无法在 120 秒内安排任务。这表明资源匮乏，通常是在磁盘访问方面。

irqbalance可能会有帮助，但这听起来不太明显。您能为我们提供此消息的背景信息吗dmesg，特别是其后的堆栈跟踪？

此外，这是不是误报。这并不是说任务挂起了永远，这个说法完全正确。但这并不意味着这对你来说是个问题，如果你没有注意到任何用户影响，你可以决定忽略它。

这不是由以下原因造成的：

  • CPU 问题（或者更确切地说，这是极不可能发生的硬件故障），
  • 内存问题（不太可能是硬件故障，但不会多次发生；而不是进程缺少 RAM oom-killed），
  • 再次缺乏交换oom-killer。

在某种程度上，您可能会将此归咎于内存不足，因为剥夺系统在 RAM 中的数据缓存会导致更多 I/O。但这并不像“内存不足”那么简单。

答案2

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

然后使用以下命令提交更改：

sudo sysctl -p

帮我解决了....

答案3

我最近在我们的一个生产集群中遇到了这个错误：

11 月 11 日 14:56:41 xxx 内核：INFO：任务 xfsalloc/3:2393 阻塞超过 120 秒。

11 月 11 日 14:56:41 Xxxx 内核：未受污染 2.6.32-504.8.1.el6.x86_64 #1

11 月 11 日 14:56:41 xxx：“echo 0 > /proc/sys/kernel/hung_task_timeout_secs”禁用此消息。

..

进一步验证 sar 日志发现，同一时间内 IO 等待时间增加了。

检查硬件（物理磁盘）后发现，存在中等错误，并且物理磁盘上记录了其他 SCSI 错误，由于缺乏可分配的资源，这又阻塞了 IO。

2015 年 11 月 11 日 19:52:40：终止 pRdm 607b8000 flags=0 TimeOutC=0 RetryC=0 请求 c1173100 回复 60e06040 iocStatus 0048 retryC 0 devId:3 devFlags=f1482005 iocLogInfo:31140000

2015 年 11 月 11 日 19:52:40：DM_ProcessDevWaitQueue：进程 devId=x 中的任务管理 2015 年 11 月 11 日 19:52:40：DM_ProcessDevWaitQueue：进程 devId=x 中的任务管理

所以这是由于我们集群中的硬件错误造成的。

因此，如果您可以检查核心文件并且 ipmi 实用程序是否存在，请检查 ipmiutil/ipmitool sel elist 命令以检查问题，这样会很好。

问候，VT

答案4

您可以进入云提供商的监控界面，检查是否超出了存储指定的最大 IOps，这可以解释为什么刷新缓存数据需要很长时间。
最大 IOps 可在存储属性页面上找到。

相关内容