Tuning der zIIP-Nutzung

Dieses Kapitel enthält Vorschläge zur Vermeidung unnötiger SRB/TCB-Umschaltungen und zur Reduzierung des CPU-Mehrbedarfs für die zIIP-Unterstützung sowie zur Verbesserung des Auslagerns zum ZIIP.

Anmerkung:
Sie können die Component Switch Statistics des Natural-Systemkommandos ZIIP zur Anzeige einer Liste der Komponenten benutzen, die TCB-Umschaltungen verursachen (siehe zIIP-Komponenten-Umschaltstatistik).


CPU-Zeitbegrenzung - FETCH-Operationen

Der Natural-Profil-/Session-Parameter MT (Maximale CPU-Zeit) bewirkt, dass jedes Mal, wenn Natural ein Programm auf Level 1 startet, eine z/OS-Timer-Service-Anforderung ausgeführt werden muss. Dadurch wird Natural gezwungen, sich vom zIIP abzuschalten. Die Standardeinstellung ist MT=60, um Endlosschleifen in Natural-Anwendungen zu verhindern. Daher wird der Timer jedes Mal neu gestartet, wenn Natural auf eine Level 0-Programmebene zurückfällt. Dies geschieht auch beim FETCH-Statement: Jedes Mal, wenn ein Programm geladen wird, muss der Timer zurückgesetzt werden.

Die Standardeinstellung ist MT=60, um Endlosschleifen in Natural-Anwendungen zu vermeiden. Die Software AG empfiehlt, MT=0 zu setzen, wenn eine Sitzung läuft, in der viele FETCH-Statements ausgeführt werden. Dadurch wird verhindert, dass Natural Timer-Makros verwendet, und es werden unnötige SRB/TCB-Umschaltungen vermieden.

3GL-Programmaufrufe

Natural muss die Verwendung von zIIP jedes Mal abschalten, wenn ein 3GL-Programm ausgeführt wird, da Natural nicht weiß, ob in dem/den externen Subprogramm(en) z/OS-Serviceaufrufe erfolgen.

Darüber hinaus darf Natural nur in Natural-Programmiersprache geschriebenen Code auf ein zIIP auslagern. Benutzerdefinierter Code, der in einer anderen Programmiersprache geschrieben wurde, darf nicht ausgelagert werden.

Der Aufruf von 3GL-Programmen innerhalb einer Natural-Schleife erzwingt viele SRB/TCB-Umschaltungen und damit viel zusätzlichen CPU-Rechenaufwand. Ein hoher Anteil an 3GL-Code reduziert die Entlastungsmöglichkeiten von Natural-Sitzungen. Solche Sitzungen sind für den Betrieb mit aktiviertem zIIP nicht geeignet.

Natural Multi-Fetch-Datensatzabruf

Executing an Adabas access statement in Natural, causes at least one WAIT SVC call and forces Natural to switch off from the zIIP. You can reduce the number of switches by exploiting the multi-fetch capabilities of Natural:

Die Ausführung einer Adabas-Zugriffsanweisung in Natural verursacht mindestens einen WAIT-SVC-Aufruf und zwingt Natural, sich vom zIIP abzuschalten. Sie können die Anzahl der Wechsel reduzieren, indem Sie die Multi-Fetch-Fähigkeiten von Natural nutzen:

  Ohne Multi-Fetch Mit Multi-Fetch
Gelesene Datensätze 100.000 100.000
Anzahl der Wechsel in den SRB-Modus 100.000 12.500
Gesamte Enklave-CPU-Zeit 5.389 ms 958 ms

Weitere Informationen zur Multi-Fetch-Funktion finden Sie unter Multi-Fetch-Klausel im Abschnitt Daten in einer Adabas-Datenbank aufrufen im Leitfaden zur Programmierung .

Sortierverarbeitung - SORT-Parameter

External sorts are not processed on the zIIP. An external sort would require several database SRB/TCB switches for SORTIN and SORTOUT processing (mostly four switches per record), thus significantly slowing down your session when running zIIP-enabled.

Externe Sortierungen werden im zIIP nicht verarbeitet. Eine externe Sortierung würde mehrere Datenbank-SRB/TCB-Umschaltungen für die SORTIN- und SORTOUT-Verarbeitung erfordern (meist vier Schaltungen pro Datensatz), wodurch Ihre Sitzung bei aktiviertem zIIP erheblich verlangsamt wird.

Die Verwendung von Natural SORT reduziert die Anzahl der SRB/TCB-Umschaltungen auf eine Umschaltung.

  Externes Sortieren verwenden Natural SORT verwenden
Gelesene Datensätze 1.145 1.145
Anzahl der Wechsel in den SRB-Modus 3.435 1.148
Gesamte Enklave-CPU-Zeit 155 ms 70 ms

SORT-Parameter

Sie können den Natural-Profilparameter SORT angeben, um die externe Sortierung zu umgehen und das interne Natural SORT zu verwenden, z. B:

SORT=(WRKSIZE=1000,EXT=OFF)

Zwischenspeicherung (Caching) der Druck- und Arbeitsdateien

Die Verwendung von Arbeitsdateien oder Druckern führt zu E/A-Unterbrechungen, die Natural zwingen, sich vom zIIP abzuschalten. Sie können unnötige Unterbrechungen vermeiden, indem Sie Cache-Puffer definieren, die für die E/A-Verarbeitung von Druck- und Arbeitsdateien verwendet werden. Diese Cache-Puffer werden verwendet, um die Daten so lange wie möglich im Kern zu halten und Daten in größeren Blöcken zu lesen oder zu schreiben.

Die Cache-Puffer werden mit dem Schlüsselwort-Subparameter PWCSIZE des Profilparameters ZIIP definiert, zum Beispiel:

ZIIP=(PWCSIZE=(300,200,300))

Die Puffergrößen werden in KB interpretiert. Sie geben den Druckpuffer, den Lesepuffer und den Schreibpuffer an. Puffergrößen von mehreren 100 KB sind ausreichend.

Umleitung von primären Ein-/Ausgaben auf einen Cache-Puffer

Primäre Ein-/Ausgaben unterliegen nicht dem Caching. Stattdessen ist die Größe des Terminal-E/A-Puffers relevant. Dieser Puffer wird entweder geleert, wenn er voll ist, oder wenn eine E/A durch ein INPUT-Statement ausgelöst wird.

Sie können den Natural-Profilparameter MAINPR verwenden, um die Programmausgabe von der Natural-Systemausgabe zu trennen und die Primärausgabe für CMPRINT auf einen zusätzlichen Drucker umzuleiten, der mit einem Cache-Puffer verarbeitet wird.

Beispiel für die Verwendung von Cache-Puffern

Wenn Ihre Anwendung einen Ausdruck mit einer Zeilengröße von 132 Zeichen erstellt, reduziert ein Druck-Cache von 132 KB die SRB/TCB-Umschaltungen beim Drucken um den Faktor 1000. Das bedeutet, dass Natural nicht für jede Zeile umschaltet, sondern nur einmal pro 1000 Zeilen oder 20 Seiten.

  WRITE (1) ohne Cache WRITE (1) mit Cache
Geschriebene Zeilen 10.000 10.000
Anzahl der Wechsel in den SRB-Modus 10.003 10
Gesamt-CPU-Zeit der WLM-Enklave 386 ms 68 ms

Für die Behandlung der Arbeitsdatei erhält man ein ähnliches Ergebnis:

  READ WORK FILE (1) ohne Cache READ WORK FILE (1) mit Cache
Geschriebene Zeilen 10,000 10,000
Anzahl der Wechsel in den SRB-Modus 10,478 5
Gesamt-CPU-Zeit der WLM-Enklave 641 ms 305 ms

Überwachung der Cache-Nutzung

Sie können die Nutzung des Cache-Puffers mit dem Natural-Systemkommando BUS überwachen.

Beginn der AnweisungslisteUm die Puffer-Cache-Nutzung zu überwachen:

  • Geben Sie das folgende Systemkommando ein:

    BUS

    Im Bericht zur Puffernutzungsstatistik Buffer Usage Statistics werden dann die von den Cache-Puffern verwendeten Größen ausgegeben:

    12:50:28               ***** NATURAL BUS UTILITY *****              2012-04-03
    
    User SAG                 - Buffer Usage Statistics -            OpSYS z/OS
    
     No. Name    Type    Size      Used   Perc.  MaxUsed   Perc.  MaxSize   Perc.
    ------------------------------------------------------------------------------
     18  PCACHE    V   512000        32    0.0    511958  100.0
     21  WCACHEO   V   307200        32    0.0    306947   99.9  
     26  WCACHE01  V   512000        32    0.0    511992  100.0
     
    ------------------------------------------------------------------------------
    ThrdSize   Total  1382656    166593   12.0      2000   54.9    33480      1.6
      2000K  (in KB)   1351K      163K             742K             33K
    ------------------------------------------------------------------------------
    
    Nat9995 Natural session terminated normally.
    • PCACHE ist der Cache für alle Druckausgaben.

    • WCACHEO ist der Cache für das Statement WRITE WORK FILE.

    • WCACHEnn ist der Cache für das Statement READ WORK FILE.

Für Statements, die Ausgaben erzeugen (z.B. WRITE oder WRITE WORK FILE), wird nur ein Cache-Puffer zugewiesen, auch für mehrere Dateien. Für das Statement READ WORK FILE wird pro Arbeitsdatei ein Puffer zugewiesen. Die Puffer werden nur belegt, wenn sie verwendet werden.

Ausführliche Informationen über die Puffernutzungsstatistiken (Buffer Usage Statistics) finden Sie im entsprechenden Abschnitt SYSTP Utility in der Utilities-Dokumentation.

Angabe der Thread-Größe - THSIZE-Parameter

Im Batch-Modus und unter TSO weist Natural normalerweise einen internen Puffer mit einem GETMAIN- oder FREEMAIN-Anforderung an das Betriebssystem zu. Jede Speicheranforderung beinhaltet einen SVC-Aufruf (Supervisor Call) und erfordert einen Wechsel zurück in den TCB-Verarbeitungsmodus.

Sie können die Anzahl der GETMAIN- oder FREEMAIN-Anforderungen reduzieren, indem Sie eine Thread-Größe mit dem Natural-Profilparameter THSIZE angeben. Natural weist dann die angegebene Menge an Speicherplatz mit einem GETMAIN zu und bedient danach alle Pufferanforderungen aus dem zugewiesenen Thread-Speicher, ohne das Betriebssystem erneut aufzurufen.

Am Ende einer Natural-Sitzung können Sie mit dem Bericht Buffer Usage Statistics (siehe Beispielbildschirm) die Puffer- und Thread-Auslastung überprüfen und feststellen, ob die definierte Thread-Größe (MaxUsed) ausreicht, um alle von der Sitzung verwendeten Puffer zuzuweisen.