![[z/OS]](../images/ngzos.gif)
Zeitlimitwerte: Richtlinien für die Änderung von Zeitlimitwerten
In dieser Datei sind allgemeine Zeitgebervariablen und Tools zur Überwachung dieser Bedingungen für die Zeitlimitüberschreitung aufgelistet.
Eine allgemeine Regel ist, dass Sie Zeitlimitwerte nur erhöhen sollten, wenn Sie alle anderen Mittel ausgeschöpft haben. Denkbar ist eine Erhöhung der Zeitlimitwerte auch als temporäre Maßnahme, wenn Sie verhindern möchten, dass viele Speicherauszüge nach abnormalen Beendigungen aufgrund von Zeitlimitüberschreitungen die Systemleistung beeinträchtigen. Wenn Sie die Zeitlimitwerte erhöhen, ohne die Zeitlimitüberschreitung genau zu diagnostizieren, erreichen Sie möglicherweise nur, dass abnormale Beendigungen und Speicherauszüge für dieselbe Zeitlimitüberschreitung seltener auftreten oder die Leistung des Systems bzw. der Anwendung abnimmt.
Informationen zum Festlegen von Werten für diese Zeitgebervariablen sowie zur Zuordnung dieser Variablen zu internen Variablen enthält der Artikel Verhalten mit Zeitlimitwerten steuern
(Einige WebSphere-Variablen sind zur besseren Lesbarkeit auf mehrere Zeilen aufgeteilt.)
WebSphere-Variable und ihre Beziehung, falls vorhanden, zu anderen Zeitgebern | Überwachung der Verarbeitung für diesen Typ von Zeitlimitüberschreitung: | Wenn Sie den Wert anpassen möchten, berücksichtigen Sie Folgendes: |
---|---|---|
WLM-Zeitlimit Für HTTP-Aufgaben und Scalable Messaging Support wird der WLM-Zeitgeber nicht gesetzt, und nur das ConnectionResponseTimeout ist wirksam (deckt das gesamte Zuteilungsfenster ab). |
SMF stellt Daten für die Zeit in der WLM-Warteschlange bereit | Wie lange es dauert, bis Aufgaben zu einem Servant gelangen, hängt davon ab, wie viele Servants von WLM gestartet werden, wie viele Servants WLM starten darf, auf wie viele Serviceklassen die Arbeit verteilt ist, wie viele Aufgaben Sie abrufen usw. |
ConnectionIOTimeOut Ohne. |
Dieses Verhalten ist nicht einfach zu überwachen. Durch Aktivierung eines Tracepunkts würde zwar angezeigt, ob ein Client aufgrund dieser Zeitlimiteinstellung fehlgeschlagen ist, das Tracing beeinträchtigt jedoch die Leistung. |
|
ConnectionResponseTimeout Wenn die Anwendungskomponente Transaktionen startet, können auch Transaktionszeitgeber betroffen sein. |
Dieses Verhalten ist nicht einfach zu überwachen, aber der Controller beendet die Servantregion mit abnormaler Beendigung EC3 für diese Zeitlimitüberschreitung. |
|
ConnectionKeepAliveTimeout Ohne. Alle anderen Zeitgeber beziehen sich auf Arbeitsprozesse, dieser Zeitgeber steuert Situationen, in denen keine Arbeit vorhanden ist. |
Ohne. | Zeitraum zwischen Anforderungen bzw. Aufwand für das Einrichten einer neuen Sitzung. Sie möchten im Leerlauf befindliche Sitzungen eine Weile halten, um die Einführungskosten für neue Sitzungen zu vermeiden. Die Sitzungen sollen jedoch nicht unbegrenzt gehalten werden, da die Summierung der Ressourcennutzung schließlich ein Problem darstellt. |
Zeitlimit für
Anforderung (ORB-Service) Ohne. Diese Variable ist ein clientseitiges Zeitlimit und bezieht sich nur auf IIOP. |
Keine andere als die Überwachung der auf der Clientseite auftretenden Zeitlimits. | Wie lange soll der Client warten? |
Keep-Alive-Zeitlimit für ORB-Listener
Keep-Alive-Zeitlimit für ORB-SSL-Listener Ohne. Diese Variablen beziehen sich auf die Sitzungsaktivität in Leerlaufphasen und gelten ausschließlich für IIOP, damit diese Zeitgeber nicht mit dem Zeitgeber ConnectionKeepAliveTimeout interagieren. |
Informationen zu
den SOCK_TCP_KEEPALIVE-Werten und deren Folgen enthält TCP/IP APAR PQ18618. |
Ist ein Zeitlimit für im Leerlauf befindliche Sitzungen sinnvoll? Normalerweise haben diese Sitzungen kein Zeitlimit, was Ressourcen binden kann. Das Ermitteln eines Zeitlimits erfordert Datenaustausch im Netz zwischen TCP/IP-Stacks. Es kann unerwünschte Folgen, Datenverkehr für Sitzungen zu produzieren, die sich ansonsten im Leerlauf befinden. |
Zeitlimit für Gesamtlebensdauer der Transaktion Diese Variable kann von Anwendungen bis zum Maximalwert, der von der Variable "Maximales Transaktionszeitlimit" angegeben wird, überschrieben werden. Dadurch wird der Zeitraum, den eine Anwendung für die Ausführung ihrer Transaktionen festlegen kann, begrenzt. Ausgabezeitgeber können ebenfalls bewirken, dass Arbeitsvorgänge ein Zeitlimit überschreiten, aber Transaktionszeitgeber und Ausgabezeitgeber erkennen sich gegenseitig nicht. |
Der Controller setzt Nachricht BBOT0003W ab, um eine Zeitlimitüberschreitung anzuzeigen, und beendet den Servant (Region) mit den EC3-Ursachencodes 04130002 oder 04130005 für abnormale Beendigung. |
|
Maximales Transaktionszeitlimit Diese Variable begrenzt den Zeitraum, den eine Anwendung für die Ausführung ihrer Transaktionen festlegen kann. Wenn die Variable "Maximales Transaktionszeitlimit" nicht gesetzt ist, werden Anwendungstransaktionen von dem in der Variablen "Zeitlimit für Gesamtlebensdauer der Transaktion" angegebenen Zeitlimit gesteuert. |
Ohne. | Dieselben Hinweise
wie für transaction_ defaultTimeout |
transaction_recoveryTimeout Ohne. |
Ohne. | Sperren werden gehalten, während ein Controller auf andere Controller wartet, die erforderlich sind, um unklare Transaktionen aufzulösen. Wie lange sollen diese Sperren gehalten werden? |
server_region_request_cputimeused_limit | Dieses Verhalten lässt sich nicht so leicht überwachen, aber der Controller beendet eine Anforderung, wenn das angegebene CPU-Nutzungszeitlimit abgelaufen ist. |
|
|
Dieses Verhalten lässt sich nicht so leicht überwachen, aber der Controller beendet den Servant mit dem Abend-Code EC3, wenn der Prozentsatz nicht reagierender Threads dieser Bedingung entspricht. |
|