Серверный узел Ignite переходит в OOM с огромными скоплениями в ConcurrentMap, TcpCommunicationSpi # recoveryDescs

Question

При запуске в нашей настройке масштабного теста мы замечаем, что узел сервера зажигания выходит из строя после нескольких дней работы.

При просмотре дампа кучи я замечаю, что ConcurrentMap, org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi # recoveryDescs накопил много сообщений («неподтвержденные сообщения» для Java-документа) в нескольких записях карты, а именно приведенный ниже ArrayDeque, кажется, содержит много орг.apache.ignite.internal.util.nio.GridNioRecoveryDescriptor.msgReqs

Любая идея о том, что может привести к такой утечке?

Мы также видим проблемы с длинными транзакциями, блокировками и т. Д. В журналах.Но что меня беспокоит, так это то, что некоторые клиентские узлы ведут себя неправильно, и я подозреваю, что в данном случае это не должно приводить к тому, что серверный узел переходит в OOM.

У любого есть какие-либо подсказки, предложения или замечания по этомуусловия, как избежать / обойти это?В основном, даже если один или несколько клиентов ведут себя неправильно, я бы хотел предотвратить сбой узла сервера с помощью OOM.

Например, поможет ли установка более низкого значения slowClientQueueLimit?В настоящее время я установил его на 1023, что на единицу меньше значения для messageQueueLimit, установленного на 1024.

В этой конкретной настройке у нас просто есть один серверный узел и около 25 нечетных клиентских узлов, и все они работаютв наложенной сети Docker Swarm (некоторые из них будут обновлять большое количество кешей внутри транзакции, в основном открывать trx, получать блокировки некоторых ключей, а затем обновлять несколько кешей через jcache apis перед закрытием trx, я подозреваю, что эта блокировкаключей, но это отдельный вопрос, о котором я задам другой вопрос).

Мы работаем с версией 2.4 и используем интеграцию Spring (планируем обновить в ближайшее время).

Спасибо Muthu

Обновление (16.10.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сообщения получены.В случае, если узел Ignite не получает подтверждения для org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setUnacknowledgedMessagesBufferSize коммуникационных сообщений, он закрывает соединение и повторно отправляет все не распакованные сообщения после восстановления соединения.

Из того, что я вижу (при условии, что все настройки TcpCommunicationSpi оставлены по умолчанию) IПредполагается, что ваши ключи и значения кеша или рабочие данные, если вы используете вычисления (т.е. сообщения Ignite, используемые для транспорта), довольно большие, возможно, десятки или сотни мегабайт.Поэтому уменьшение org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi#setAckSendThreshold должно помочь.

Дайте мне знать, если это работает.

Яков