Java Ignite服务器节点在ConcurrentMap、TcpCommunicationSpi#recoveryDescs中出现大量累积

在scale测试设置中运行时，我们注意到ignite服务器节点在运行几天后会发出OOM

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

知道是什么导致了这种“泄漏”的发生吗

我们在日志中也看到了长事务、锁等问题。但让我担心的是，尽管有几个客户端节点出现了异常行为，但我怀疑这里的情况仍然不会导致服务器节点失控

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

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

在这个特定的设置中，我们只需要一个服务器节点&大约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>

---

您可以尝试减少

org.apache.ignite.spi.communication.tcp.tcpccommunicationspi#setacksendsthreshold

。默认值为32。让我们为拓扑中的所有节点（服务器和客户端）尝试8或更少

解释如下

为了确保通信消息传递，Ignite为每个

org.apache.Ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold

接收的消息发送确认。如果Ignite节点未接收到

org.apache.Ignite.spi.communication.tcp.TcpCommunicationSpi#setUnackedMessagesBufferSize

c的确认通信消息它关闭连接，并在重新建立连接后重新发送所有未确认的消息

根据我所看到的（假设TcpCommunicationSpi的所有设置都保留为默认设置），如果您使用compute（即用于传输的Ignite消息），我将假设您的缓存键和值或作业数据非常大，可能是几十或几百兆。因此，减少

org.apache.ignite.spi.communication.tcp.tcpccommunicationspi#setacksendsthreshold

应该会有所帮助

让我知道它是否有效

---

Yakov

您可以尝试减少

org.apache.ignite.spi.communication.tcp.tcpccommunicationspi#setacksendsthreshold

。默认值为32。让我们为拓扑中的所有节点（服务器和客户端）尝试8或更少

解释如下

为了确保通信消息传递，Ignite为每个

org.apache.Ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold

接收的消息发送确认。如果Ignite节点未接收到

org.apache.Ignite.spi.communication.tcp.TcpCommunicationSpi#setUnackedMessagesBufferSize

c的确认通信消息它关闭连接，并在重新建立连接后重新发送所有未确认的消息

根据我所看到的（假设TcpCommunicationSpi的所有设置都保留为默认设置），如果您使用compute（即用于传输的Ignite消息），我将假设您的缓存键和值或作业数据非常大，可能是几十或几百兆。因此，减少

org.apache.ignite.spi.communication.tcp.tcpccommunicationspi#setacksendsthreshold

应该会有所帮助

让我知道它是否有效

---

Yakov

感谢@Yakov提供的有用建议和推理。我将尝试并更新它。我们确实有一些缓存值稍大。我也有一些关于TcpCommunicationSpi的非默认设置，我已经在上面的问题中更新了这些设置。希望它们可以。不过，有一个问题，第二个设置的当前默认值是多少ing？，

org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setunacknowledmessagesbuffersize

@lmk您可以在这里检查逻辑

org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#recoveryDescriptor

。默认情况下，它应该是

32*128=4096

，但如果您更改了

queueLimit

，它是计算的基于提供的值进行了更新。谢谢！谢谢@Yakov提供的有用建议和推理。我将尝试并更新。我们确实有一些缓存值稍大。我在问题中还更新了TcpCommunicationSpi上的一些非默认设置。希望它们可以。但有一个问题，当前默认设置是什么第二个设置的值？，

org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setunacknowledmessagesbuffersize

@lmk您可以在这里检查逻辑

org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#recoveryDescriptor

。默认情况下，它应该是

32*128=4096

，但是如果您更改了

queueLimit

它是根据提供的值计算的。谢谢！