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).
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.
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.
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 .
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 |
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)
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.
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.
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 |
Sie können die Nutzung des Cache-Puffers mit dem
Natural-Systemkommando BUS
überwachen.
Um 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.
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.