Question

目前我的应用程序在IO中被定期阻止，输出非常低。我使用一些命令来跟踪进程。

使用 jstack 我发现应用程序挂在FileOutputStream.writeBytes。

通过使用 strace -f -c -p pid 来收集系统调用信息，我发现了。对于正常情况，它有futex和write syscalls。但是当它变得不正常时，只有futex系统调用。该应用程序一直在调用futex，但都失败并抛出ETIMEDOUT，就像这样：

<futex resumed>  =-1 ETIMEDOUT (Connecton timed out)
futex(Ox7f823, FUTEX_WAKE_PRIVATE,1)=0
futex(Ox7f824, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME) =-1<unfinished>
<futex resumed>  =-1 ETIMEDOUT (Connecton timed out)
futex(Ox7f823, FUTEX_WAKE_PRIVATE,1)=0
futex(Ox7f824, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME) =-1<unfinished>

此问题会定期发生，并持续数小时或数小时，然后再恢复正常。

按照惯例，当在IO中被阻止时， echo 3＆gt; / proc / sys / vm / drop_caches 总是让它暂时恢复正常。我用Google搜索并找到了一些类似的proleam，如下所示。

闰秒。不起作用，我们的系统的ntpd被停止了。
透明的巨页错误。 https://bugzilla.redhat.com/show_bug.cgi?id=879801 这与我的问题非常相似，但我的khugepaged进程是正常的，负载总是接近于零。 Escipally drop_caches 也适用于我的应用程序。我的系统也是多核和大内存。它对我不起作用。所以任何人遇到同样的问题或熟悉这个问题？

有关我系统的一些信息。操作系统：Redhat 6.1，核心版本2.6.31

JDK：1.7.0_05

CPU：X5650,24cores

内存：24GB和48GB

Answer 1

除了时钟跳变和前面提到的（相当古老的）THP内核错误外，Java意外阻止IO的另一个常见原因是读取very slow and blocking /dev/random，有些库更喜欢使用io.StringIO来执行/ dev / urandom。

分辨这是否是罪魁祸首的简便方法：

sudo mv /dev/random /dev/random.real
sudo ln -s /dev/urandom /dev/random

...然后重新启动应用程序，并查看它是否停止IO阻止。测试完成后，您可能想要恢复/ dev / random：

sudo mv /dev/random.real /dev/random

...并与应用程序供应商一起打开错误，要求在适当的地方使用/ dev / urandom。

Java定期挂起futex和非常低的IO输出

1 个答案: