![[z/OS]](../images/ngzos.gif)
WLM-Optimierungstipps (Workload-Management) für z/OS
Sie können die Administrationskonsole verwenden, um den JCL-Prozedurnamen für den Servant und den JCL-Parameter angeben und damit eine dynamische Anwendungsumgebung einrichten. Aber auch in einer dynamischen Anwendungsumgebung müssen Sie die WLM-Ziele für Ihre Umgebung festlegen.
Mit der Wahl angemessener WLM-Ziele kann der Durchsatz Ihrer Anwendung erheblich beeinflusst werden. Den Adressräumen von WebSphere Application Server muss eine relativ hohe Priorität eingeräumt werden. Bei der Festlegung der WLM-Ziele für Ihr z/OS-System können Sie folgende Aktionen ausführen:
- Klassifizieren Sie Location Service Daemons und Controller als SYSSTC oder mit hoher Geschwindigkeit.
- Verwenden Sie für die Klassifizierung von Geschwindigkeitszielen für Anwendungsserver die STC-Klassifizierungsregeln. Am Anfang des Lebenszyklus des Servants oder falls Sie den Parameter ManageNonEnclaveWork in IEAOPTxxWLM auf yes (ja) gesetzt haben:
- Unter dieser Klassifizierung wird die Java-Garbage-Collection ausgeführt. Die Java-Garbage-Collection ist ein CPU- und speicherintensiver Prozess. Wenn Sie das Geschwindigkeitsziel also zu hoch ansetzen, könnte die GC mehr Systemressourcen binden, als erwünscht ist. Wenn Ihr Java-Heapspeicher richtig optimiert ist, sollte die Garbage-Collection für jeden Servant nicht mehr als 5 % der Zeit beanspruchen. Die Angabe der richtigen Priorität für die GC-Verarbeitung ist ebenfalls notwendig, da andere Arbeiten im Servant während der Garbage-Collection größtenteils gestoppt werden.
- JSP-Dateien werden auf der Basis dieser Klassifizierung kompiliert. Falls Ihr System so konfiguriert ist, dass diese Kompilierungen in der Laufzeit ausgeführt werden, kann eine zu niedrige Geschwindigkeit zu längeren Verzögerungen führen, weil auf den Abschluss der JSP-Kompilierungen gewartet werden muss.
Falls der Parameter ManageNonEnclaveWork in IEAOPTxxWLM auf no (nein) gesetzt ist oder nicht angegeben wird, werden die meisten Java-Garbage-Collection- und JavaServer-Pages-Kompilierungen entsprechend den Serviceklassenbedingungen verwaltet, die für den Servant aufgestellt wurden, der die Kompilierungen verarbeiten soll.
Die Anwendungsaufgaben werden unter dem Arbeitsmanager klassifiziert.
- Setzen Sie erreichbare Antwortzeitziele.
Eine typische Zielsetzung wäre, dass 80 % der Arbeit in 0,25 Sekunden ausgeführt werden. Geschwindigkeitsziele für die Ausführung von Anwendungen sind nicht sinnvoll und sollten vermieden werden.
- Legen Sie Ihre Ziele über mehrere Zeiträume fest.
Diese Strategie kann hilfreich sein, wenn Sie unterscheidbare Transaktionen mit kurzer und langer Laufzeit in derselben Serviceklasse haben. Nach Möglichkeit sollten Sie diese Arbeiten jedoch in eine andere Serviceklasse filtern. Sind diese Arbeiten in einer anderen Serviceklasse enthalten, werden Sie auch einem anderen Servant zugeteilt, sodass der WLM die Ziele flexibler verwalten kann.
- Definieren Sie eindeutige WLM-Berichtsklassen für Servant-Regionen und für Anwendungen, die in der Anwendungsumgebung ausgeführt werden. Wenn Sie eindeutige WLM-Berichtsklassen definieren, ist Resource Measurement Facility (RMF) in der Lage, Leistungsdaten detaillierter zu berichten.
- Verwenden Sie die Variablen wlm_maximumSRCount=x und
wlm_minimumSRCount=y, um die maximale und minimale
Anzahl der Servants zu steuern, wenn in der WLM-Konfiguration keine Grenzwerte definiert sind.
Zum Festlegen von Werten für diese Variablen klicken Sie in der Administrationskonsole auf Server > Servertypen > WebSphere-Anwendungsserver und wählen Sie den entsprechenden Anwendungsserver aus.
Fehler vermeiden: Wenn Sie für die Variable wlm_maximumSRCount einen Wert angeben, muss dieser größer-gleich der Anzahl an Serviceklassen sein, die für diese Anwendungsumgebung definiert sind. Wenn der Wert kleiner ist als die Anzahl der definierten Serviceklassen, können Zeitlimitüberschreitungen auftreten, weil keine ausreichende Anzahl von Servants verfügbar ist.gotcha
- Sehen Sie sich die im Workload-Aktivitätsbericht des RMF-Nachprozessors berichteten Ergebnisse
in regelmäßigen Abständen an:
- Transaktionen pro Sekunde (stimmt nicht immer mit der Transaktionsrate des Clients überein)
- Durchschnittliche Antwortzeiten (und Verteilung der Antwortzeiten)
- Genutzte CPU-Zeit
- Verschiedenen Verzögerungen zugeordnete Antwortzeit in Prozent
- Achten Sie auf Arbeit, die standardmäßig den Wert SYSOTHER verwendet. Gemäß den Informationen im Artikel Subsystem-Specific Performance Hints im Information Center für z/OS können bei der Arbeit in Subsystemen, die Enklaven verwenden, Leistungseinbußen auftreten, wenn die Servicedefinition nicht klassifiziert ist. Wenn Sie für diese Arbeit keine Klassifikationsregeln in Ihre Servicedefinition aufnehmen, wird automatisch die Serviceklasse SYSOTHER zugeordnet, die ein ressourcenabhängiges Ziel hat.
- Achten Sie auf die folgende Fehlernachricht in einer Steuerregion: BBOO0037E Function
IWMSRCRR failed with RC=8,REASON=00000868. Einschränkung: Im Hinblick auf die WLM-Verarbeitung auf Ihrem z/OS-System mit aktiven WAS-Adressbereichen tritt diese Nachricht auf, sobald die Anzahl der Server, die versuchen, sich bei WLM zu registrieren, die maximal zulässige Anzahl von 256 überschritten hat. Dies bedeutet, dass der 257. Server (und die nachfolgenden Server), beim Versuch, sich bei WLM zu registrieren, mit dieser Nachricht fehlschlagen. Die maximal zulässige Anzahl von 256 ist eine festgelegte Systemeinschränkung, die nicht geändert werden kann.