WebSphere MQ Connection Tuning

Question

Ich habe eine Anwendung, die MDB, Aktivierungsspezifikationen und Warteschlangenverbindungsfactorys verwendet, um Nachrichten von WMQ abzurufen/zu stellen. Die Anwendung erwartet eine maximale Belastung von 80 Tps. Sowohl Websphere Application Server als auch WMQ sind geclustert und jeder Anwendungsserver verbindet sich mit einem separaten Host und Kanal. Die Methode onMessage der Anwendung wird so implementiert, dass Sitzung und Verbindung geschlossen werden, nachdem die Nachricht verbraucht und die Antwort gesendet wurde.

Gemäß unserer Konfiguration haben wir WAS-Version 8.5, IBM MQ-Warteschlangenmanager Version 7, max. Serversitzungen für Akt-Spezifikation auf 40 für jeden Knoten festgelegt. Maximale Verbindungsanzahl in Connection Factory zu 40 für jeden Knoten und maximale Sitzung im Sitzungspool der Verbindungsfactory zu 10. Jetzt erwarten wir bei Spitzenlast maximal 80 MQ Channel Instance, aber gemäß der Untersuchung können wir sehen, dass sie über 200 geht verursacht ein Problem, wenn das maximale Instanzenlimit erreicht ist.

Ist dies passiert, weil max Sitzung im Session-Pool der Verbindung Factory auf 10 festgelegt ist?

Ist es möglich, dass, obwohl wir die Sitzung und die Verbindung in onMessage schließen, immer noch eine Verbindung mehr als eine Sitzung haben kann. Wenn das der Fall ist, ist es sinnvoll, diese Eigenschaft auf 1 zu setzen? Auch kann es eine Eigenschaft geben, die bei WMQ eingestellt ist, die diesen Anstieg in MQ-Kanalinstanzen verursachen könnte.

Answer 1

Sie erwähnen keine bestimmten Versionen von WAS oder MQ, und es könnte Probleme bei einer bestimmten Version geben, die das Verhalten ändern würden, aber im Allgemeinen sollte es wie unten beschrieben funktionieren.

IBM hat eine nette Technote "TCP/IP Connection usage between WebSphere Application Server V7 and V8, and WebSphere MQ V7 (and later) explained", die zu diesem Thema ins Detail geht.

Sie erwähnen nicht, was Sie haben den SVRCONN-Kanal SHARECNV festgelegt, wie unten wird sich auf die Anzahl der Kanal-Instanzen beobachtet, ich nehme den Standardwert von 10 für die Berechnungen.

Beachten Sie, dass Block Anführungszeichen unten sind von der Technote

---

• wir max-Server-Sitzungen für act spec 40 für jeden Knoten

gesetzt haben Der obige Link besagt:

Maximale Anzahl der Gespräche = maximale Server-Sitzungen + 1

Maximale Anzahl der Gespräche = 40 + 1 = 41

Der Link auch heißt:

Maximalanzahl TCP/IP Kanalinstanzen = Maximale Anzahl von Gespräche/SHARECNV für den Kanal

Maximale Anzahl von TCP/IP Kanalinstanzen verwendeten = 41/10 = 5 (aufgerundet auf die nächste Verbindung)

---

• max Verbindung Zählen Sie in Connection Factory zu 40 für jeden Knoten
• max. Sitzung im Sitzungspool der Verbindungsfactory zu 10.

Maximale Anzahl der Gespräche = Connection Pool Maximale Verbindungen + (Connection Pool Maximale Verbindungen * Session Pool Maximale Verbindungen)

Maximale Anzahl der Gespräche = 40 + (40 * 10) = 440

Maximale Anzahl von TCP/IP-Kanalinstanzen = Maximale Anzahl von Konversationen/SHARECNV für den verwendeten Kanal

Maximale Anzahl der TCP/IP-Kanal Instanzen = 440/10 = 44

---

Wenn Ihr MQ SVRCONN des Kanals SHARECNV auf 10 gesetzt wurde, dann sollten Sie nicht mehr als 49-Kanal-Instanzen für jeden Kanal haben basierend auf jedem Knoten, der mit einem separaten Kanal verbunden ist.

Wenn Sie 200-Kanal-Instanzen schlagen würde ich Ihre SHARECNV vermuten ist weniger als 10. Wenn es 1 die versuchen würde, die maximale Anzahl von Kanal Instanzen wurde 481 zu schaffen würde, bis zu der durch die MAXINST von begrenzt werden würde der Kanal zu 200.

---

Nachdem eine Anwendung mit einer JMS-Verbindung und verschlossen beendet hat, wird er aus dem aktiven Pool zu dem freien Pool bewegt, wo es für die Wiederverwendung zur Verfügung steht. Die Verbindungspool-Eigenschaft Unused timeout definiert, wie lange eine JMS-Verbindung im freien Pool verbleibt, bevor sie getrennt wird. Diese Eigenschaft hat den Standardwert von 1800 Sekunden, also 30 Minuten.

---

Jeden JMS-Verbindung, die von einer WebSphere MQ-Messaging-Provider Connection Factory hat einen zugehörigen JMS Session-Pool, die in der gleichen Art und Weise arbeiten, wie Verbindungspools angelegt. Die maximale Anzahl von JMS-Sitzungen, die von einer einzelnen JMS-Verbindung erstellt werden können, wird durch die Connection Factory-Sitzungs-Pool-Eigenschaft Maximale Anzahl von Verbindungen bestimmt. Der Standardwert dieser Eigenschaft lautet 10.

Eine Konversation wird gestartet, wenn eine JMS-Sitzung zum ersten Mal erstellt wird, und bleibt aktiv, bis die JMS-Sitzung geschlossen wird, da sie länger als der Wert von Nicht verwendete Timeout-Eigenschaft des Sitzungspools.

Wenn Ihre App die Sitzung und Verbindung in onMessage schließen, wird die Verbindung zum freien Pool zur Wiederverwendung bewegt und die Sitzung zu dem freien Pool zur Wiederverwendung bewegt wird, wird die MQ-Kanal-Instanz nicht bis zum jeweiligen geschlossen werden Timeout ist erreicht.

Wenn Sie Ihren maximalen Kanal zu halten, zählen weniger als 200 dann könnte man tune Ihre Session Pool Maximale Verbindungen)-1, die mit Ihren Aktivierungs Spezifikationen kombiniert und ein SHARECNV (1) würde max out bei 121 Kanal-Instanzen.

Sie können auch den SHARECNV-Wert des Kanals erhöhen, wodurch die Kanalinstanzen durch diese Nummer geteilt werden.

Es ist möglich, dass Ihre Verbindungen oder Sitzungen nicht richtig geschlossen werden und Sie ein "Leck" haben.