WildFly 12+中Linux文件句柄(管道)泄漏

Question

我试图确定我所观察到的行为是否正确，或者WildFly是否泄漏了文件句柄描述符。

在我们从WildFly 11升级到14之后的标准性能测试中，我们遇到了一个关于太多打开文件的问题。在深入研究了一些事情之后，看起来WildFly打开的管道数量实际上在增加。

为了帮助重现这个问题，我创建了一个简单的JSF2.2应用程序，其中包含一个大型映像(100 To，以简化测试)。我使用标准JSF资源URL检索图像：

/contextroot/javax.faces.resource/css/images/big-image.png.xhtml

还尝试添加总括并使用未映射的资源处理程序URL：

/contextroot/javax.faces.resource/css/images/big-image.png

添加Omnifaces并没有改变我所看到的行为，我只是把它包括在内，因为我们最初认为它可能是一个促成因素。

我所看到的行为：

WildFly启动并报告说它有两个线程匹配default task-*，这是task-core-threads的默认值。

如果我为我的大映像发送5个并发请求，就会生成3个新的default task-*线程来处理请求。还将创建3个新的Linux管道。

如果我停止请求并等待2分钟(task-keepalive的默认值)，3个线程将被删除。管子仍然开着。

周期性的--我相信大约每4.5分钟就会发生某种清理，从上面的台阶上遗留下来的管道会被移除。

然而..。如果移除原来的两个工作线程之一，例如任务-1、任务-3和任务-4，则任务-2和任务-5将永远不会被清除。

随着时间的推移，这些管道加起来，据我所知，它们从未被移除。这是什么地方的泄密，如果是的话，在哪里？JSF？WildFly？暗拖？

我尝试过的事情：

WildFly 14、17和18

有和没有全面的(2.7和3.3)

将min和max线程更改为相同的--这样可以防止句柄的积累，但我不想沿着这条路线走下去。

Answer 1

在将WildFly运行时从8迁移到11之后，就开始遇到这个问题了。

Java11将默认的GC算法更改为G1。在G1中，老一代对象是非常有选择地收集的，并且只有在通过某个堆占用率阈值之后才能收集。如果您有很少的对象被提升到老一代，并且帮助达到这个阈值，那么org.xnio.nio.NioXnio$FinalizableSelectorHolder就有可能在那里堆积很长一段时间，保留打开的文件描述符。

在我的例子中，切换垃圾收集以使用并发标记和扫描解决了这个问题，尽管我相当肯定G1可以调优以更积极地收集老一代。-XX:-G1UseAdaptiveIHOP和-XX:InitiatingHeapOccupancyPercent是要玩的开关。另一种方法可能实际上是减少老一代堆(–XX:NewRatio)或整个堆的大小。