JGroups еда памяти

У меня в настоящее время есть проблема с моей jgroups конфигурацией, вызывая тысячи сообщений, застревающих в NAKACK.xmit_table. На самом деле все они, кажется, заканчивают в xmit_table, и другой дамп от несколько часов спустя указывает, что они никогда не намереваются уехать также...

Это - конфигурация стека протоколов

UDP(bind_addr=xxx.xxx.xxx.114;
bind_interface=bond0;
ip_mcast=true;ip_ttl=64;
loopback=false;
mcast_addr=228.1.2.80;mcast_port=45589;
mcast_recv_buf_size=80000;
mcast_send_buf_size=150000;
ucast_recv_buf_size=80000;
ucast_send_buf_size=150000):
PING(num_initial_members=3;timeout=2000):
MERGE2(max_interval=20000;min_interval=10000):
FD_SOCK:
FD(max_tries=5;shun=true;timeout=10000):
VERIFY_SUSPECT(timeout=1500):
pbcast.NAKACK(discard_delivered_msgs=true;gc_lag=50;retransmit_timeout=600,1200,2400,4800;use_mcast_xmit=true):
pbcast.STABLE(desired_avg_gossip=20000;max_bytes=400000;stability_delay=1000):UNICAST(timeout=600,1200,2400):
FRAG(frag_size=8192):pbcast.GMS(join_timeout=5000;print_local_addr=true;shun=true):
pbcast.STATE_TRANSFER

Сообщение запуска...

2010-03-01 23:40:05,358 INFO  [org.jboss.cache.TreeCache] viewAccepted(): [xxx.xxx.xxx.35:51723|17] [xxx.xxx.xxx.35:51723, xxx.xxx.xxx.36:53088, xxx.xxx.xxx.115:32781, xxx.xxx.xxx.114:32934]
2010-03-01 23:40:05,363 INFO  [org.jboss.cache.TreeCache] TreeCache local address is 10.35.191.114:32934
2010-03-01 23:40:05,393 INFO  [org.jboss.cache.TreeCache] received the state (size=32768 bytes)
2010-03-01 23:40:05,509 INFO  [org.jboss.cache.TreeCache] state was retrieved successfully (in 146 milliseconds)

... указывает, что все прекрасно до сих пор.

Журналы, набор к предупреждать-уровню не указывает, что что-то неправильно за исключением occational

2010-03-03 09:59:01,354 ERROR [org.jgroups.blocks.NotificationBus] exception=java.lang.IllegalArgumentException: java.lang.NullPointerException

то, которое я предполагаю, не связано, так как это было замечено ранее без проблемы памяти памяти.

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

UDP имеет

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

в то время как NAKACK имеет...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

... и огромный xmit_table.

Каждая машина имеет два экземпляра JChannel, один для ehcache и один для TreeCache. Неверная конфигурация означает, что они оба совместно используют тот же diagnositics mcast адрес, но это не должно создавать проблему, если я не хочу отправить право сообщений диагностики? Однако у них действительно, конечно, есть различные адреса mcast для сообщений.

Попросите разъяснения, у меня есть большая информация, но я немного не уверен в том, что релевантно в этой точке.

5
задан Sebastian Ganslandt 4 March 2010 в 08:29
поделиться

1 ответ

Оказывается, один из узлов кластера вообще не получил никаких многоадресных сообщений. Это заставляло все узлы цепляться за свои собственные xmit_tables, поскольку они не получали никаких сообщений о стабильности от «изолированного» узла, о том, что он получил их сообщения.

Перезапуск AS, изменение адреса многоадресной рассылки решили проблему.

4
ответ дан 15 December 2019 в 00:58
поделиться