Dieser Abschnitt behandelt Engpässe im openUTM- und BCAM-Umfeld, die zu Antwortzeitverlängerungen in den einzelnen Phasen führen können. Er zeigt auf, wie diese Engpässe messtechnisch erkannt und auf welche Art sie behoben bzw. gemildert werden können.
Phasen 1 und 10: Netzlaufzeiten
Allgemeine Hinweise zum LAN-Anschluss finden Sie im Abschnitt "Netzanschluss".
Phase 2: Warten bis zur Annahme der eingehenden Nachricht durch BCAM (Inbound Flow Control)
Steuerungsmechanismen zur Kontrolle des Datenflusses schützen das Transportsystem vor Datenüberflutung durch die Partner. Dadurch wird verbindungsspezifisch ein (schneller) Sender an die Verarbeitungsgeschwindigkeit eines (langsamen) Empfängers angepasst.
BCAM schützt so seinen Speicherpool, der allen Anwendungen und Verbindungen zur Verfügung steht. In Phasen, in denen der BCAM-Pool stark ausgelastet ist, hindert BCAM seine Partner daran, Nachrichten ins BS2000-System zu senden. Dadurch kann es zu steigenden Antwortzeiten kommen.
Ursache für eine länger oder dauerhaft anhaltende hohe Auslastung des BCAM-Pools können Anwendungen sein, die ihre Nachrichten langsam abholen. Auch eine, für die zu erbringende Verarbeitungsleistung, zu geringe Poolgröße kann zu einer hohen Auslastung des BCAM-Pools führen.
openSM2 stellt Messdaten für die Analyse der Auslastung des BCAM-Pools zur Verfügung, siehe Messprogramm RESPONSETIME im Handbuch "openSM2" [18].
BCAM selbst erlaubt es mit dem Kommando /BCMON und durch Analyse der Werte der Konsolmeldung BCA0B21 zu ermitteln, ob ein Engpass im BCAM-Puffer vorliegt.
Kurzbeschreibung der Vorgehensweise:
Ermittlung der eingestellten Maximalwerte (optional) mit:
/SHOW-BCAM-PARAMETERS PARAMETER=*LIMITSEinschalten des BCAM-Monitoring (Ausgabe der Messwerte alle <n> Sekunden):
/BCMON MODE=ON,RECORD=RES-MEM,SEC=<n>Beschreibung der wichtigsten Ausgabe-Werte der Konsolmeldung BCA0B21:
USED-BCAM-MIN-I: minimale BCAM-Pufferbelegung für eingehende Nachrichten in KB
LIMIT-ACT: aktuelle obere Grenze für die Pufferbelegung in KB
Indikator für eine hohe Auslastung des BCAM-Puffers durch eingehende Nachrichten:
(USED-BCAM-MIN-I) * 4 > LIMIT-ACT
Alternativ oder ergänzend zu den obigen Punkten kann mit /BCSET THRESHOLD-MSG=ON eine Warnmeldung angefordert werden.
Dann wird die Konsolmeldung BCAB021 ausgegeben, wenn BCAM wegen Pool-Engpass die eingehenden Nachrichten länger als 5 Sekunden bremst (oder keine Sendeanforderungen der Anwendung annehmen kann, siehe Phase 7).
Diese Warnmeldung wird mit /BCSET THRESHOLD-MSG=OFF wieder ausgeschaltet.Optimierungsmaßnahme bei einem Engpass im BCAM-Pool:
Mit dem Kommando /BCMOD RESMEM=<n> sollte der maximal zulässige Schwellwert deutlich erhöht werden (ideal wäre: <n>=3*LIMIT-ACT).
Phasen 3 und 8: Bearbeitung der Ein- bzw. Ausgangs-Nachricht in BCAM
Die Zeitwerte für diese Phasen sollten im niedrigen einstelligen Bereich (in Millisekunden) liegen.
Phase 4: Warten auf openUTM
Die Zeit, die zwischen der Auftragserteilung an openUTM und der Annahme des Auftrags verstreicht, wird als INWAIT-Zeit bezeichnet. Sie wird pro Anwendung ermittelt und ist in der INPROC-Zeit enthalten.
openSM2 erfasst die INWAIT-Zeiten (wie auch die INPROC- , REACT- und OUTPROC-Zeiten) in 5 Zeitintervallen, den so genannten Buckets. Buckets können nur global, nicht aber anwendungsspezifisch eingestellt werden. Zur Vereinfachung der Überwachung sollten Intervall-Einteilung so vorgenommen werden, dass alle nicht akzeptablen Zeiten in das letzte Intervall fallen (Overrun-Wert).
Beispiel
Die normale Antwortzeit beträgt 100 - 200 ms (typisch für große /390-Server). Es sollen kurzfristige Schwankungen bis zum Faktor 2 toleriert werden. Eine länger andauernde Verdopplung der Antwortzeit soll aber nicht toleriert werden.
Die Buckets in openSM2 sollten demnach so eingestellt werden, dass im Overrun-Intervall alle INWAIT-Zeiten gezählt werden, die 400 ms oder größer sind, z.B. mit
/SET-BCAM-CONNECTION-PARAMETER INWAIT-BUCKETS=(50,100,200,400)
Mit dieser Anweisung werden die Buckets so eingestellt, dass im ersten Intervall alle Wartezeiten < 50 ms, im zweiten Intervall alle Wartezeiten zwischen 50 und 100 ms, im dritten Intervall alle Wartezeiten zwischen 100 und 200 ms, im vierten Intervall alle Wartezeiten zwischen 200 und 400 ms und im Overrun-Intervall alle Wartezeiten > 400 ms gezählt werden.
Mit den Komponenten INSPECTOR oder ANALYZER von openSM2 müssen nun (für jede Anwendung) die Messwerte des Overrun-Intervalls überwacht werden. Die Werte werden in Prozent (bezogen auf die im Messintervall erfassten Zeitwerte) dieser Applikation ausgegeben. Ab einem Prozentwert von 10 oder höher deutet dies auf Engpässe bei der Auftragsannahme durch die UTM-Tasks hin.
Messmöglichkeit in openUTM
Mit dem UTM-Kommando KDCINF STAT werden mehrere nützliche UTM-Messwerte ausgegeben, siehe openUTM-Handbuch "Anwendungen administrieren" [20]. Für die Analyse, ob die Zahl der UTM-Tasks einen Engpass darstellen könnte, liefert der Ausgabewert %Load einen wichtigen Hinweis. Dieser gibt die mittlere Auslastung aller UTM-Tasks des letzten Messintervalls an. Ein zumindest kurzzeitiger Engpass deutet sich an, wenn der Wert größer als 90 (%) wird.
Schwellwertüberwachung der UTM-Taskanzahl mit openSM2
Ein sich anbahnender Engpass an UTM-Tasks lässt sich mit dem Messreport UTM-Applikation von openSM2 erkennen. Dazu müssen von diesem Report die Werte für die Dauer einer Transaktion in Sekunden (DT), die Anzahl der Transaktionen pro Sekunde (TX) und die Anzahl der UTM-Tasks für die Applikation (UT) ermittelt werden.
Damit kann die mittlere Auslastung der UTM-Tasks einer Anwendung errechnet werden:Load (in %) = 100 * DT * TX / UT.
Im INSPECTOR von openSM2 kann dieser errechneten Wert einer
Schwellwertüberwachung unterworfen werden. Bei Überschreitung eines Wertes von 90 (%) kann z.B. eine entsprechende E-Mail an die Systembetreuung erzeugt werden.
Optimierungsmaßnahme
Mit dem UTM-Kommando KDCAPPL TASKS=<n> kann die Anzahl der UTM-Tasks applikationsspezifisch und schrittweise solange erhöht werden, bis die INWAIT-Zeiten in einem akzeptablen Bereich liegen. Die so gefundene optimale Taskanzahl sollte in der Startparameter-Datei von openUTM eingetragen werden. Sie wirkt dann ab dem nächsten Anwendungsstart. Übersteigt <n> den im KDCDEF-Lauf festgelegten maximalen Wert, so muss dieser Maximal-Wert erhöht und ein neuer KDCDEF-Lauf gestartet werden.
Bei der Veränderung der Anzahl der UTM-Tasks müssen immer auch die Anzahl der TAC-Klassen und die Anzahl der Tasks in diesen TAC-Klassen berücksichtigt werden. Ebenso ist ein gewisser Puffer für Lastspitzen zu berücksichtigen.
Anmerkung
Nur wenn deutlich mehr UTM-Tasks als nötig gestartet werden, kann dies zu geringen Leistungseinbußen durch die etwas höhere Hauptspeicher- und CPU-Nutzung führen.
Phase 5 und 6: Bearbeitung der Transaktion
Die in dieser Phase (und in der Phase 7) anfallende Zeit wird im BCAM-Connection-Report als REACT-Zeit ausgewiesen.
Tuning der IO-Performance beim Zugriff auf die KDCFILE
Neben den in diesem Handbuch beschriebenen Maßnahmen bei der Hardware und in BS2000 kann die Performance von Anwendungen mit hohen Transaktionsraten auch in openUTM durch optimierte Schreibzugriffe auf die KDCFILE verbessert werden.
Dazu können in openUTM die Pagepools und/oder der Wiederanlaufbereich aus der KDCFILE ausgelagert werden. Diese ausgelagerten Bereiche werden nun selbst wieder auf mehrere Volumes verteilt.
Beispiel:
Der Pagepool soll auf 2 Public Volumes, der Wiederanlaufbereich auf 4 Public Volumes verteilt werden:
/CREATE-FILE FILE-NAME=<filebase>.P01A, - SUPPORT=*PUBLIC-DISK(VOLUME=<v1>,SPACE=*RELATIVE(PRIMARY-ALLOCATION=666)) /CREATE-FILE FILE-NAME=<filebase>.P02A, - SUPPORT=*PUBLIC-DISK(VOLUME=<v2>,SPACE=*RELATIVE(PRIMARY-ALLOCATION=666)) /CREATE-FILE FILE-NAME=<filebase>.R01A, - SUPPORT=*PUBLIC-DISK(VOLUME=<v3>,SPACE=*RELATIVE(PRIMARY-ALLOCATION=300)) /CREATE-FILE FILE-NAME=<filebase>.R02A, - SUPPORT=*PUBLIC-DISK(VOLUME=<v4>,SPACE=*RELATIVE(PRIMARY-ALLOCATION=300)) /CREATE-FILE FILE-NAME=<filebase>.R03A, - SUPPORT=*PUBLIC-DISK(VOLUME=<v5>,SPACE=*RELATIVE(PRIMARY-ALLOCATION=300)) /CREATE-FILE FILE-NAME=<filebase>.R04A, - SUPPORT=*PUBLIC-DISK(VOLUME=<v6>,SPACE=*RELATIVE(PRIMARY-ALLOCATION=300))
Außerdem müssen in der KDCDEF die folgenden Parameter in der MAX-Anweisung geändert werden: PGPOOLSFS=2, RECBUFFS=4.
Im KDCDEF-Lauf werden dann die oben definierten Dateien verwendet, wobei das KDCDEF-Programm eventuell die Werte für PRIMARY- und SECONDARY-ALLOCATION modifiziert. Ohne obige Kommandos würde KDCDEF die Dateien selbst anlegen (ohne Volume-Zuweisung).
Nach dem Neustart von openUTM werden die neuen Dateien verwendet.
Steuerung der UTM-Aufträge durch TAC-Klassen
Ähnlich der Kategoriesteuerung mit PCS (siehe Abschnitt "PCS-Konzept") können Transaktionen in openUTM in so genannte "TAC-Klassen" aufgeteilt werden. Diese TAC-Klassen können mit zwei nicht kombinierbaren Methoden gesteuert werden:
Prioritätensteuerung
Prozessbeschränkung
Details zur Auftragssteuerung in openUTM finden Sie im openUTM-Handbuch "Anwendungen generieren" [21].
Einsatzempfehlung:
Bei der Aufteilung der TACs in TAC-Klassen muss darauf geachtet werden, dass höherpriore TAC-Klassen nicht durch TACs aus nieder-prioren TAC-Klassen gebremst werden (Verwendung von blockierenden Aufrufen).
Es wird empfohlen, nicht mehr als 3 oder 4 TAC-Klassen zu definieren.
Die Prioritätensteuerung dient vor allem dazu, dass bei (kurzfristigen) Überlasten lang laufende TACs aus nieder-prioren TAC-Klassen kurz laufende TACs aus höher-prioren TAC-Klassen nicht behindern. Somit werden hoch-priore Transaktionen unter Ausnutzung aller gestarteten Prozesse bevorzugt.
Die Prozessbeschränkung dient dazu, dass lang laufende TACs andere, kurz laufende TACs nicht behindern können. Der Vorteil dieser Variante liegt darin, dass hier immer dafür gesorgt werden kann, dass genügend freie UTM-Tasks für neue (und wichtige) TACs zur Verfügung stehen.
Zusätzlich können TACs durch Angabe der RUNPRIO in der TAC-Anweisung gesteuert werden. Dies ist aber nur für höchst-priore TACs zu empfehlen und ist mit dem Prioritätengefüge aller in BS2000 ablaufenden Tasks abzustimmen.
Weitere Performance-Hinweise zu openUTM:
Überwachung der Cache Hit-Rate
Mit dem UTM-Kommando KDCINF STAT (siehe oben, Phase 4, "Messmöglichkeit in openUTM") sollte (zumindest gelegentlich) überprüft werden, ob die Trefferquote im Pagepool des UTM-Caches ausreichend hoch ist. Bei Werten unter 90 (%) sollte der UTM-Cache eventuell vergrößert werden (siehe openUTM-Handbuch "Anwendungen generieren" [21]).
Einsatz von UTM-F
Diese UTM-Variante ist hauptsächlich für Anwendungen mit "retrieval"-Zugriffen und keinen bis sehr wenigen Updates geeignet. Sie dient zur Vermeidung von Ein-/Ausgaben bei reduzierter Funktionalität (hinsichtlich Ausfallsicherheit und Wiederanlauf).
Phase 7: Warten vor BCAM
Diese Phase ist im BCAM-Connection-Report ein Teil der REACT-Zeit (siehe Phase 5).
Analog zu Phase 2 kann BCAM den Steuerungsmechanismen des Partners zur Kontrolle des Datenflusses unterliegen. Dies ist erkennbar durch ZWR-Werte > 0 (ZWR=Zero Window Receive) im openSM2-Report BCAM. BCAM nimmt zwar in solchen Situationen eine gewisse zu versendende Datenmenge der Anwendung an, wird jedoch bei Überschreiten eines Grenzwertes die Annahme von weiteren Daten verweigern.
BCAM verzögert die Annahme von Daten auch in Phasen, in denen der BCAM-Pool stark ausgelastet ist. Ursache für eine länger oder dauerhaft anhaltende hohe Auslastung des BCAM-Pools können Verbindungen sein, die der Kontrolle des Datenflusses unterliegen. Auch eine, für die zu erbringende Verarbeitungsleistung, zu geringe Poolgröße kann zu einer hohen Auslastung des BCAM-Pools führen.
Analog zu Phase 2 bietet BCAM eine Überwachungsmöglichkeit.
Zeigt die Meldung BCA0B21 hohe Werte für USED-BCAM-MIN-O an, so sollte wie in Phase 2 der BCAM-Pool vergrößert werden.
Phase 8 und 9: Verzögerung bei der Übergabe ins Netz
Die Zeit in Phase 8 (reine BCAM-Verarbeitung) liegt im einstelligen Millisekunden-Bereich. Die Zeiten für Phase 8 und 9 sind gemeinsam in der OUTPROC-Zeit enthalten. Eine Überwachung der OUTPROC-Zeit analog zur INPROC-Zeit wird empfohlen (siehe oben, "Phase 4: Warten auf openUTM"). Hohe Werte im Overrun-Intervall deuten auf mögliche Probleme der Netzperformance hin (z.B. durch Fehlfunktionen in Routern oder Switches).