Question

我们的企业应用程序部署在Jboss wildfly 8.2中。问题是，经过一个月的jboss重启后，文件系统操作速度减慢到十分之一。即如果我在我的apache中托管了一个大小为1 GB的简单静态文本文件，将其下载到我的本地框就可以完成3分钟。但一个月后，同样的手术需要30分钟。重新启动jboss后，问题立即消失。系统中没有明显的CPU，内存或IO峰值。

打开文件的数量接近550万，最高为570万。＆＃34; lsof -p＆＃34;的输出仅显示5k记录，而倾销整个＆＃34; lsof＆＃34;然后gret jboss pid显示了一个巨大的数字。

$$$ lsof | wc -l </ em> - ＆gt;的 3552282

$$$ lsof | awk＆＃39; {print $ 2}＆＃39; | grep jboss-pid | wc -l </ em> - ＆gt;的 2760622

在jboss开设的270万个文件中，有120万个文件如下所示。重启jboss后，打开的文件会关闭，但这个数字会不断增加，最终导致速度变慢。这肯定指向套接字泄漏，但我该如何进一步调试呢？

$$$ grep＆＃34; protocol：TCP＆＃34; /tmp/lsof.41321 -c - ＆gt; 的 1203852 的

java 41321 106902 sf-admin 2724u sock 0,6 0t0 1256280582协议：TCP

java 41321 106902 sf-admin 2725u sock 0,6 0t0 1247336438 protocol：TCP

java 41321 106902 sf-admin 2726u sock 0,6 0t0 1247336439 protocol：TCP

Answer 1

我真的没有一个很好的答案，但如果可以，我建议你尽可能升级到WildFly 10。看起来在较新版本的WildFly中修复了一些泄漏。

看起来所有这些都是在WildFly 9中修复的，如果需要，它仍然允许Java 7。 WildFly 10需要Java 8。

Answer 2

我们最终从1.1.8分支机构手动更换了底板罐。这与＆＃34; tcp-keep-alive＆＃34; ＆安培; ＆＃34;只读超时＆＃34;属性为我们解决了这个问题。

undertow-core-1.1.0.Final.jar  
undertow-servlet-1.1.0.Final.jar  
undertow-websockets-jsr-1.1.0.Final.jar

<http-listener name="default" socket-binding="http" max-parameters="5000" max-post-size="-1" **tcp-keep-alive="true" read-timeout="300000"**/>

Jboss wildfly socket泄漏

2 个答案: