java - Ignite 服务器节点因 ConcurrentMap 中的大量累积而 OOM，TcpCommunicationSpi#recoveryDescs

Question

在规模测试设置中运行时，我们注意到 ignite 服务器节点在运行几天后出现 OOM。

在查看堆转储时，我注意到 ConcurrentMap，org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#recoveryDescs 已经积累了大量消息(每个 Java 文档的“未确认消息”) )在映射的多个条目中，即下面的 ArrayDeque 似乎包含很多 org.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor.msgReqs

知道什么可能导致这种“泄漏”发生吗？

我们确实在日志中看到了长事务、锁定等问题。但令我担心的是，尽管有一些客户端节点行为不当，我怀疑这里的情况应该仍然不会导致服务器节点 OOM。

有人对如何避免/解决这个问题有任何线索、建议或意见吗？基本上，即使一个或多个客户端行为不当，我也希望防止服务器节点因 OOM 崩溃。

例如，为 SlowClientQueueLimit 设置较低的值会有帮助吗？目前我已将其设置为 1023，这比设置为 1024 的 messageQueueLimit 值小 1。

在这个特定的设置中，我们只有一个服务器节点和大约 25 个客户端节点，它们都在 docker swarm 覆盖网络中运行(其中一些会更新事务内的大量缓存，基本上是打开 trx ，获取某些键上的锁，然后在关闭 trx 之前通过 jcache api 更新几个缓存，我怀疑这种键锁定是一个问题，但这是一个单独的问题，我将在另一个问题中询问)。

我们正在运行 2.4 版并使用 Spring 集成(计划很快升级)。

谢谢穆图

更新(10/16/18):以下是所有节点上的 TcpCommunicationSpi 设置，

             <bean class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
                 <!-- Override message queue limit for incoming and outgoing messages -->
                 <property name="messageQueueLimit" value="1024"/>
                 <property name="sharedMemoryPort" value = "-1" />
                 <property name="slowClientQueueLimit" value="1023"/>
                 <property name="idleConnectionTimeout" value="3600000"/>
             </bean>

Answer 1

您可以尝试减少org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold 。默认值为 32。让我们为拓扑中的所有节点(服务器和客户端)尝试 8 或更少。

解释如下。

为了确保通信消息传递，Ignite 为每个 org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold 发送 acks收到的消息。如果 Ignite 节点未收到 org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setUnacknowledgedMessagesBufferSize 的 acks通信消息它会关闭连接并在重新建立连接后重新发送所有未确认的消息。

据我所知(假设 TcpCommunicationSpi 的所有设置均保留默认值)，如果您使用计算(即点燃用于传输的消息)，我会假设您的缓存键和值或作业数据非常大，可能有数十或数百个兆。因此，减少org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold应该有帮助。

让我知道它是否有效。

雅科夫