Утечка памяти Hazelcast

Я столкнулся с проблемой при использовании логики кластера Hazelcast IAtomic. Моя конфигурация такая, что у меня есть 4 узла, и первый узел является главным для hazelcast. Второй узел будет главным, если первый узел выйдет из строя. Шаги сценария:

  1. Я убиваю первый и третий узел одновременно.
  2. Hazelcast решил выбрать новый главный узел, потому что главный узел умер. Новый главный узел - это второй узел.
  3. 2-й узел пытается выполнить миграцию, и здесь система получает нехватку памяти из-за Hazelcast. Hazelcast снова пытается подключить третий узел (как бесконечный цикл). В итоге не будет памяти и система выбросит OutOfMemoryException

Журналы Hazelcast ниже

    Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnection
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Connection[id=21282, /198.168.10.14:50491->/198.168.10.14:5702, endpoint=[198.168.10.14]:5702, alive=false, type=MEMBER] closed. Reason: Connection closed by the other side
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnector
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Connecting to /198.168.10.14:5702, timeout: 0, bind-any: true
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpAcceptor
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Accepting socket connection from /198.168.10.14:56774
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnectionManager
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Established socket connection between /198.168.10.14:5702 and /198.168.10.14:56774
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnectionManager
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Established socket connection between /198.168.10.14:56774 and /198.168.10.14:5702
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnectionManager
WARNING: [198.168.10.11]:5702 [dev] [3.10.2] Wrong bind request from [198.168.10.11]:5701! This node is not the requested endpoint: [198.168.10.14]:5702
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnection
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Connection[id=21284, /198.168.10.14:5702->/198.168.10.14:55083, endpoint=null, alive=false, type=MEMBER] closed. Reason: Wrong bind request from [198.168.10.11]:5701! This node is not the requested endpoint: [198.168.10.14]:5702
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpAcceptor
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Accepting socket connection from /198.168.10.14:51198
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnectionManager
INFO: [198.168.10.11]:5702 [dev] [3.10.2] Established socket connection between /198.168.10.14:5702 and /198.168.10.14:51198
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnectionManager
WARNING: [198.168.10.11]:5702 [dev] [3.10.2] Wrong bind request from [198.168.10.11]:5701! This node is not the requested endpoint: [198.168.10.14]:5702
Jul 10, 2018 2:52:36 PM com.hazelcast.nio.tcp.TcpIpConnection

Узел 1 и узел 3 работают на одном сервере. Узел 2 и узел 4 работают на одном сервере

Конфигурация (для инициализации hazelcast):

Config config = new Config();
    NetworkConfig network = config.getNetworkConfig();
    JoinConfig join = network.getJoin();
    join.getMulticastConfig().setEnabled(true);
    join.getTcpIpConfig().setEnabled(false);

    config.setNetworkConfig(network);
    config.setInstanceName("instance");

person Okay Atalay    schedule 10.07.2018    source источник
comment
Я использую Hazelcast версии 3.10.2   -  person Okay Atalay    schedule 10.07.2018
comment
Возможно, что оставшимся двум участникам не хватит места в куче для хранения всех данных четырех участников, отсюда и oome. Учли ли вы общий размер данных в кластере (включая резервные копии), а также общий размер кучи?   -  person sertug    schedule 10.07.2018
comment
оставшиеся узлы имеют 2 ГБ памяти при инициализации. А еще у Сервера есть 4 Гб дополнительной памяти. всего используется 6 ГБ памяти. я думаю этого достаточно. Если уничтожить только узел 1 или узел 3, проблем не будет. Проблема воспроизводится, только node1 (master) и node3 уничтожаются одновременно.   -  person Okay Atalay    schedule 10.07.2018
comment
Кто-нибудь может предложить мне способ решения этой проблемы?   -  person Okay Atalay    schedule 11.07.2018
comment
Вариант использования и описание неясны. Лучше всего, если вы можете прикрепить журналы всех участников, а также сделать дамп кучи -XX:HeapDumpOnOutOfMemoryError во время OOME, чтобы его можно было исследовать. Вы можете прикрепить журналы и, возможно, снимок экрана с дампом кучи в сообщении Google на странице groups.google .com / forum / #! forum / hazelcast   -  person sertug    schedule 11.07.2018
comment
Собственно, сценарий прост. всего, есть 4 узла. первые 2 узла работают на server1, и первый узел является главным узлом. последние 2 узла работают под управлением server2. когда я убиваю первые 2 узла одновременно, hazelcast пытается снова и снова подключать умерший узел. Имею дамп кучи. В моем дампе кучи 3-й узел инициализировал 1 ГБ памяти, а server2 имеет всего 8 ГБ памяти. Также я сохранил максимум 50 длинных данных на hazelcast. Я прикрепил результат анализа кучи к вопросу   -  person Okay Atalay    schedule 11.07.2018


Ответы (1)


Когда я получаю дамп кучи. Я использую MAT для анализа, и результат:  Результат MAT

Результат MAT

person Okay Atalay    schedule 11.07.2018
comment
Журналы просто указывают на то, что tcp-соединение для участника потеряно, о дальнейшем нет никакой информации. Я тоже не вижу скриншотов по этим ссылкам, они как-то битые. Было бы лучше, если бы вы могли открыть новую ветку в googlegroups с прикрепленными полными журналами и скриншотами. - person sertug; 11.07.2018