Ein bisschen Hintergrundwissen zum Szenario.
Ich habe eine verteilte Anwendung, die auf RH6.5 läuft und JMS (OpenMQ 4.5.2) verwendet, um Nachrichten zwischen Hosts zu senden.
Ein Host (Host A) empfängt Informationen von Netzwerkelementen wie Routern und Switches und leitet diese Informationen zur Verarbeitung an einen anderen Host (Host B) weiter. JMS läuft auf Host B.
Diese Nachrichten, die durch JMS fließen, liegen im Durchschnitt bei etwa 100 Nachrichten pro Sekunde und können ohne Probleme Spitzen von mehreren hundert Nachrichten aufweisen.
Gelegentlich beobachte ich, dass der Nachrichtenfluss zum Stillstand kommt, nichts erreicht Host B, obwohl Host A immer noch mit ähnlicher Geschwindigkeit Daten vom Netzwerk empfängt. Wenn dies geschieht, beansprucht der JMS-Prozess auf Host B die gesamte CPU.
Mithilfe von netstat -o ist mir außerdem aufgefallen, dass der Recv-Q des JMS-Sockets auf der Host-B-Seite sehr hoch ist:
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 268439 0 HostB:9030 HostA:53712 ESTABLISHED off (0.00/0/0)
Auf der Seite von Host A ist der Send-Q ebenfalls hoch:
Proto Recv-Q Send-Q Local Address Foreign Address State Timer
tcp 0 68736 HostA:53712 HostB:9030 ESTABLISHED probe (17.25/0/0)
Mir ist auch der Wert „probe“ im Timer aufgefallen. Bei der Suche im Internet habe ich nur wenige Informationen zur Bedeutung dieses Wertes gefunden.
Die Frage ist also:
Was bedeutet ein Timerwert von „probe“, und könnte dies auf ein Problem beim Lesen vom oder Schreiben in den Socket hinweisen?