mémoire manger JGroups

Question

J'ai actuellement un problème avec ma configuration JGroups, causant des milliers de messages s'embourber dans le NAKACK.xmit_table. En fait, tous semblent se retrouver dans la xmit_table, et une autre décharge de quelques heures plus tard, indique qu'ils ont l'intention de ne jamais laisser non plus ...

Ceci est la configuration de la pile de protocole

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

Message de démarrage ...

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)

... indique que tout va bien jusqu'à présent.

Les journaux, mis en garde à niveau ne signifie pas que quelque chose ne va pas, sauf pour le occational

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

que je devine est sans rapport, car il a été vu précédemment sans problème de mémoire de la mémoire.

Je suis en train de creuser à travers deux décharges d'une mémoire des machines pour trouver bizarreries, mais rien jusqu'à présent. Sauf peut-être quelques statistiques des différents protocoles

UDP a

num_bytes_sent 53617832
num_bytes_received 679220174
num_messages_sent 99524
num_messages_received 99522

tandis que NAKACK a ...

num_bytes_sent 0
num_bytes_received 0
num_messages_sent 0
num_messages_received 0

... et un énorme xmit_table.

Chaque machine a deux instances JChannel, un pour ehcache et un pour TreeCache. Un misconfiguration signifie que les deux partagent la même adresse diagnositics mcast, mais cela ne devrait pas poser un problème à moins que je veux envoyer des messages de diagnostic non? Cependant, ils ont bien entendu différentes adresses MCAST pour les messages.

S'il vous plaît demander des éclaircissements, j'ai beaucoup d'informations, mais je suis un peu incertain au sujet de ce qui est pertinent à ce stade.

Answer 1

Il se trouve que l'un des nœuds du cluster n'a pas reçu de messages de multidiffusion du tout. Cela a causé tous les nœuds à accrocher à leurs propres xmit_tables, car ils ne reçoivent aucun message de stabilité à partir du nœud « isolé », indiquant qu'il avait reçu leurs messages.

Un redémarrage de UGL, en changeant l'adresse multicast a résolu le problème.