Question

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

在查看堆转储时，我注意到ConcurrentMap org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi＃recoveryDescs 积累了很多消息（每个Java文档都为“未确认消息” ）在地图的多个条目中，即下面的ArrayDeque似乎占有很多 org.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor.msgReqs

任何想法都可能导致这种“泄漏”发生吗？

我们也确实在日志中看到长事务，锁等问题。但是让我担心的是，不管有几个客户端节点行为异常，我怀疑在这种情况下，这仍然不会导致服务器节点变为OOM。

关于如何避免/解决此问题，任何人都对此有任何线索，建议或投入？基本上，即使一个或多个客户端行为不当，我也想防止服务器节点因OOM崩溃。

例如，是否为lowerClientQueueLimit设置一个较低的值会有所帮助？目前，我已将其设置为1023，这比messageQueueLimit设置为1024的值小一。

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

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

谢谢 Muthu

更新（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条消息发送一个ack。如果Ignite节点未收到org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setUnacknowledgedMessagesBufferSize通信消息的确认消息，它将关闭连接并在重新建立连接后重新发送所有未确认的消息。

从我所看到的（假设TcpCommunicationSpi的所有设置都保留为默认设置），我认为如果使用计算（即用于传输的Ignite消息），则缓存键和值或作业数据相当大，可能数十或数百梅格斯。因此，减少org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold应该会有所帮助。

让我知道它是否有效。

亚科夫

Ignite服务器节点在ConcurrentMap TcpCommunicationSpi＃recoveryDescs

1 个答案: