Hinweise zur Performance-Verbesserung

#### Search Results

Search

# Hinweise zur Performance-Verbesserung

Das Entire Operations-System basiert auf Adabas, Natural und dem Entire System Server. Deshalb beziehen sich die nachfolgenden Performance-Überlegungen speziell auf diese Komponenten bzw. auf Entire Operations selbst.

Folgende Themen werden behandelt:

- Entire System Server

- Natural

- Adabas

- Entire Operations

## Entire System Server

Wenn der Entire Operations-Monitor als Subtask des Entire System Server läuft, geben die Startup-Parameter `BPSIZE` und `BPDIRS` die Größe des Natural Buffer Pool an. Je größer der verfügbare Speicherplatz und je größer die Anzahl der Verzeichniseinträge in diesem Buffer sind, um so weniger Adabas-Aufrufe müssen erfolgen, um die vom Monitor verwendeten Natural-Objekte zu laden.

## Natural

- Falls der Monitor als separater Batch Job oder Task läuft, gelten für den Natural Batch Buffer Pool ebenfalls die zum Entire System Server gegebenen Hinweise.

- Definieren Sie den benötigten Software AG Editor Buffer Pool so groß, dass eine Auslagerung auf den EDTWORK Dataset vermieden wird. Weitere Informationen siehe Software AG Editor Buffer Pool.

## Adabas

Prüfen Sie die Adabas-Statistik, ob die Pools voll laufen, prüfen Sie die Anzahl an Throwbacks, Anzahl an Formatüberschreitungen und die Thread-Nutzung, und passen Sie die erforderlichen Parameter an.

Erhöhen Sie den Adabas Buffer LBP, um das Verhältnis zwischen Anzahl an Adabas-Aufrufen und der dafür benötigten Anzahl an physischen Ein-/Ausgaben zu verbessern. Verringern Sie die Adabas WORK IO, indem Sie den NSISN-Parameter verkleinern (evtl. müssen Sie auch den Wert des LI-Parameters erhöhen).

Nehmen Sie die Nutzung der Entire Operations-Systemdatei(en) gründlich unter die Lupe:

- Wo befinden sich diese Dateien (AC,UI/NI/MI,DS)?

- Wie schnell reagieren diese Platten auf Ein-/Ausgabeanforderungen?

- Wie steht es um die ISN- und DSN-Parameter-Wiederverwendung?

Verteilen Sie ASSO und DATA auf ungefähr so viele Platten, wie Adabas Threads aktiv sind. WORK und PLOG sollten auf separaten Platten liegen.

### LFIOP bei Adabas benutzen

Ordnen Sie die Entire Operations-Systemdatei(en) physisch neu, und führen Sie diese Maßnahme regelmäßig durch. Dadurch werden die Datensätze in der ISN-Reihenfolge angeordnet, was die Verarbeitung einiger häufig benutzter Lesevorgänge beschleunigt.

Beachten Sie, dass der Entire Operations Monitor mit der Natural-Profilparametereinstellung `WH=ON` (Warten auf Datensatz im Hold-Status) arbeitet. Falls ein Adabas-Datensatz in einer oder mehreren Entire Operations-Systemdateien durch einen Benutzer gesperrt ist (Hold-Status) und der Monitor ihn aktualisieren muss, muss der Monitor auf die Freigabe dieses Datensatzes warten. Prüfen Sie in einem solchen Fall den Inhalt der Adabas-Hold-Warteschlange auf Einträge, die auf die Systemdateien zeigen. Passen Sie die Adabas-Zeitparameter `TNAx` und `TT` so an, dass Ressourcen auch im Falle von Benutzern, die nicht mehr anwesend sind, freigegeben werden.

Anmerkung
Der Adabas-Parameter `LFIOP` bei Großrechnerplattformen ist äquivalent zum Parameter `BFIO_PARALLEL_LIMIT` in Adabas für UNIX und Windows.

## Entire Operations

- Monitor und Monitor Task Intervall

- Monitor-Tasks

- Netzwerke

- Job-Speicherort

- Aktivierung

- Früheste Startzeit

- Prüfung der Eingabebedingung

- Referenzen auf Eingabebedingungen

- Job-Ende-Prüfung

- Job-Ende-Aktionen

- Asynchrone Exit-Ausführung

- Symbol-Ersetzung

### Monitor und Monitor Task Intervall

Passen Sie die Wartezeit (Wait Interval) des Entire Operations Monitors und des Monitor Task den Erfordernissen an. Weitere Informationen siehe Profil der Monitor-Tasks in der Systemverwaltung-Dokumentation.

#### Beispiel 1

Tagsüber während der Online-Zeit braucht der Monitor sich nur alle paar Minuten zu aktivieren, wenn es nicht allzu viele Jobs gibt, die ausgeführt werden müssen.

#### Beispiel 2

Falls Sie überwiegend große Batch-Jobs haben, dann erhöhen Sie die Wartezeit des Monitors ebenfalls. Es besteht auch die Möglichkeit, die Wartezeit innerhalb eines Natural-Programms über eine Anwendungsprogrammierungsschnittstelle (API) zu ändern und dieses Programm über Entire Operations selbst aufzurufen.

### Monitor-Tasks

Um den System-Mehraufwand bei der Verwaltung der einzelnen Monitor-Tasks in vernünftigen Grenzen zu halten, sollten Sie den Monitor nicht auf zu viele unnötige Tasks verteilen. Empfohlen werden zwei bis vier Tasks. Hinsichtlich der empfohlenen Verteilung siehe Profil der Monitor-Tasks in der Systemverwaltung-Dokumentation.

### Netzwerke

Anstelle von komplexen Netzwerken mit vielen Jobs sollten Sie Unternetzwerke verwenden. Diese Unternetzwerke können in Jobs des Typs `NET` definiert werden. Das verkleinert die Warteschlangen, und die Aktivierung erfolgt nur dann, wenn alle notwendigen Bedingungen erfüllt sind.

### Job-Speicherort

Benutzen Sie Natural-Bibliotheken anstelle von sonstigen JCL-Medien. Dadurch verringert sich die Anzahl der Anforderungen an den Entire System Server. Darüber hinaus können Sie den gesamten Zugriff auf diese JCL Members mit Natural Security kontrollieren.

### Aktivierung

Versuchen Sie, die Zeit, während der die Netzwerke in der aktiven Warteschlange stehen, so kurz wie möglich zu halten. Das heißt, aktivieren Sie die Netzwerke in zeitlicher Nähe zu ihrer Startzeit. Das verringert die Anzahl der vom Monitor zu prüfenden Bedingungen.

### Früheste Startzeit

Geben Sie, falls möglich, zu jedem Netzwerk eine früheste Startzeit an. Die Prüfung der Bedingungen erfolgt dann erst nach dieser Zeit. Andernfalls wird das Netzwerk um Mitternacht (Beginn des geplanten Tages) aktiviert.

### Prüfung der Eingabebedingung

Spezielle Aktionen während der Prüfung der Eingabebedingung sind komfortabel, können aber Mehraufwand zur Folge haben. Dazu zählen:

- Eingabebedingungen, die von Dateien, Jobvariablen usw. abhängen.

- Eingabebedingungs-User Exits, die übermäßig viele Adabas-Aufrufe machen.

Vermeiden Sie redundante Prüfungen solcher Bedingungen. Es ist viel effizienter, Dummy Jobs auf solche Bedingungen warten zu lassen, die Vorgänger von mehreren anderen Jobs sind.

### Referenzen auf Eingabebedingungen

Vermeiden Sie möglichst, Referenzen auf andere Eingabebedingungen als `RUN` zu benutzen, weil diese eine Bedingungsprüfung während eines Zeitintervalls verursachen und weil dies weniger effizient ist als eine direkte `RUN`-Prüfung.

Anmerkung
`RUN`-Prüfungen sind nicht anwendbar, wenn Sie eine Verbindung zwischen Netzwerken benötigen.

### Job-Ende-Prüfung

Jede definierte Prüfung kostet Zeit und beeinflusst die Performance. Daher sollten Sie Job-Ende-Prüfungen auf das nötige Minimum beschränken. Insbesondere sollten Sie komplexe Job-Ende-Prüfungsaktionen im SYSOUT-Protokoll vermeiden.

User Exits für die Job-Ende-Prüfung können im asynchronen Betrieb benutzt werden.

### Job-Ende-Aktionen

User Exits für die Job-Ende-Aktionen können im asynchronen Betrieb benutzt werden.

### Asynchrone Exit-Ausführung

Bei jedem Exit für die Job-Ende-Prüfung (`EJC`) und für die Job-Ende-Aktionen (`EJA`) können Sie eine asynchrone Exit-Ausführung definieren. Siehe auch User Exits für die Job-Ende-Prüfung und -Aktionen.

Asynchrone Exits werden in dem oder den speziell dafür vorgesehenen Monitor-Task oder Tasks für Jobs des Typs `NAT` ausgeführt. Somit wird die Behandlung der Warteschlangen für die Job-Ende-Überprüfungen und Job-Ende-Aktionen innerhalb der allgemeinen Monitor-Tasks durch sie nicht blockiert.

#### Anmerkungen zur asynchronen Exit-Ausführung

1. Die Logik bei der Job-Netzwerkausführung bleibt die gleiche, wenn Sie einen Exit als asynchron auszuführend definieren.

2. Exits sollten nicht auf asynchrone Exit-Ausführung gesetzt werden, wenn sie eine kurze Ausführungszeit haben und nur wenige Datenbank- und Entire System Server-Aufrufe ausführen.

3. Exits sollten auf asynchrone Exit-Ausführung gesetzt werden, wenn sie eine längere Ausführungszeit haben und/oder viele Datenbank- und Entire System Server-Aufrufe ausführen.

4. Bitte beachten Sie den Mehraufwand an Job-Netzwerk-Ausführungszeit, der durch mehr Warteschlangenwechsel zwischen Monitor-Taks verursacht wird.

5. Die Ausführungszeit eines einzelnen Job-Netzwerks kann durch asynchrone Exits nicht verkürzt werden.

6. Der Durchsatz bei parallel laufenden Job-Netzwerken mit exzessiver Exit-Nutzung kann aufgrund von mehr parallelen Abläufen besser werden.

### Symbol-Ersetzung

Bei komplexen Produktionen mit oft verwendeten JCL-Rahmen sollten Sie allzu häufigen Gebrauch von Symbol-Ersetzungen vermeiden. Nehmen wir beispielsweise an, ein Job mit 100 Symbolen wird 500 mal am Tag benutzt. Vergewissern Sie sich, dass die Verwendung aller Parameter tatsächlich nötig ist.

### On this page

- Entire System Server
- Natural
- Adabas
- Entire Operations