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

17

当前正在运行一些VM和“裸机”服务器。Java的运行速度很高-有时超过400％。服务器随机挂起，并在控制台中显示以下错误：“ java-被阻止超过120秒”-kjournald，等等。

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

我更改了它所在的环境-甚至是物理服务器，并且这种情况仍在发生。

如果根据http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html，这是一个误报，我将Hang_task_timeout_secs更改为0 。

另外，没有安装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.

linux kernel

— 三通
source

15

是的，可以。

这意味着非常明确：内核无法在120秒内安排任务。这表明资源匮乏，通常是围绕磁盘访问。

irqbalance可能会有所帮助，但这听起来并不明显。您能否为我们提供此消息的周围信息dmesg，尤其是它后面的堆栈跟踪信息？

而且，这不是假阳性。这并不表示该任务将永远挂起，并且该语句完全正确。这并不意味着这对您来说是一个问题，如果您没有注意到任何用户影响，则可以决定忽略它。

这不能由以下原因引起：

CPU问题（或更确切地说，这将是不可思议的硬件故障），
内存问题（几乎不可能发生硬件故障，但不会多次发生；不会因为过程而缺少RAM oom-killed），
缺乏交换（oom-killer再次）。

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

— 皮埃尔·开利
source

没有任何内容记录到/ var / log / dmesg中，因此我只粘贴了控制台显示的内容。.当出现此情况时，系统已100％挂起。

— 2012年

该消息来自内核，它将出现在dmesg（如果最近才被记录），因为此命令将打印内核日志记录环形缓冲区。希望您的syslog设置也可以将其记录在中/var/log，但是我不知道在哪里。

— 皮埃尔·开利

该消息不会出现在中/var/log/dmesg，但是在您运行命令时可能会出现dmesg。该文件是在引导过程中创建的，通常只捕获引导时的内核消息（否则最终会滚动出内核环形缓冲区。您也可以安装/启用sysstat并查看那里报告的资源利用率。我怀疑是磁盘I / O / iowait，可能与交换有关（sysstat将有助于识别这一点）

— Edward Morbius博士2012年

@ Dr.EdwardMorbius那么我们如何解决呢？我的Zimbra服务器与此有关的一个主要问题是，该服务器在生产环境中一直运行良好，直到最近。

— 停泊

@洛佩兹：对不起，我经常不在这里。简要地说：您必须分析Java进程并找出其挂起的原因。垃圾收集是我在调优中遇到的问题（和成功的问题）之一。查找JVM垃圾回收人体工程学，并查看oracle.com/technetwork/java/javase/gc-tuning-6-140523.html，我发现增加堆的作用明显。

— Dr. Edward Morbius 2014年

6

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

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

sudo sysctl -p

为我解决了...

— 缺口
source

6

您应该解释每个设置的作用。

— kasperd '16

6

这解决了我在docker环境中遇到的类似问题。我在这里找到了一个解释：blackmoreops.com/2014/09/22/…。“默认情况下，Linux最多使用40％的可用内存进行文件系统缓存。达到此标记后，文件系统会将所有未完成的数据刷新到磁盘，从而导致随后的所有IO同步。默认情况下，时间限制为120秒。在这种情况下，IO子系统的速度不足以刷新数据...”

— Peter M

2

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

11月11日14:56:41 xxx内核：信息：任务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：“回显0> / proc / sys / kernel / hung_task_timeout_secs”会禁用此消息。

..

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

在检查硬件（物理磁盘）后，发现其中一个错误和其他SCSI错误已在一个物理磁盘上登录，由于缺乏分配资源，物理磁盘又阻塞了IO。

15/11/11 19:52:40：终止的pRdm 607b8000标志= 0 TimeOutC = 0 RetryC = 0请求c1173100回复60e06040 iocStatus 0048 retryC 0 devId：3 devFlags = f1482005 iocLogInfo：31140000

15/11/11 19:52:40：DM_ProcessDevWaitQueue：进程devId中的任务mgmt = x 11/11/15 19:52:40：DM_ProcessDevWaitQueue：进程devId = x中的任务mgmt

因此，这是由于我们集群中的硬件错误所致。

因此，如果您可以检查核心文件以及ipmi实用程序，那就很好，请检查ipmiutil / ipmitool sel elist命令以检查问题。

此致VT

— 瓦伦·托马斯
source

0

您可以转到云提供商的监视界面，并检查是否没有超过为存储指定的最大IOps，这可以解释为什么刷新刷新数据需要花费很长时间的原因。
最大IOps可在“存储属性”页面上找到。

— 伊曼纽尔
source