Performance-Überlegungen

Dieses Kapitel behandelt folgende Themen:


Übersicht

Das Entire Operations-System basiert auf Adabas, Natural und den Entire System Server (früherer Produktname: Natural Process). Deshalb beziehen sich die nachfolgenden Performance-Überlegungen auf diese Komponenten bzw. auf Entire Operations selbst.

Entire System Server

Wenn im Entire Operations Monitor ein 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 ebenfalls die zum Entire System Server gegebenen Hinweise.

  • Definieren Sie die benötigten Editor Buffer Pools so groß, dass eine Auslagerung auf den EDTWORK Dataset vermieden wird. Weitere Informationen siehe Editor Buffer Pool im Abschnitt Allgemeine Anmerkungen zur Installation.

Adabas

Prüfen Sie in der Adabas-Statistik, ob die Pools voll laufen, auf die Anzahl an Throwbacks, Anzahl an Formatüberschreitungen und die Thread-Verwendung, und korrigieren Sie die erforderlichen Parameter.

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 IOs, 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:

  • Auf welcher Platte liegen die Komponenten dieser Dateien (AC,UI/NI/MI,DS)?

  • Wie schnell reagieren diese Geräte auf Ein-/Ausgabeanforderungen?

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

Verteilen Sie ASSO und DATA auf soviele Platten, wie Adabas Threads aktiv sind. WORK und PLOG sollten auf separaten Platten liegen.

LFIOP bei Adabas 5.2 benutzen

Ordnen Sie die Entire Operations-Systemdateien 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 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, dann muss der Monitor auf die Freigabe dieses Datensatzes warten. Prüfen Sie in einem solche Fall den Inhalt der Adabas-Hold-Warteschlange auf Einträge, die auf die Systemdateien zeigen. Ändern Sie die Adabas-Zeitparameter TNAx und TT so, 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_LIMITin Adabas für Open Systems.

Entire Operations

Monitor und Monitor Task Intervall

Passen Sie den Wait Intervall 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 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 gleichermaßen die Wartezeit des Monitors. Es besteht auch die Möglichkeit, den Wait Interval innerhalb eines Natural-Programms über eine Anwendungsprogrammierungsschnittstelle (API) zu ändern und dieses Programm über Entire Operations selbst aufzurufen.

Monitor-Tasks

Um den Mehraufwand bei Systemverwaltung 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 gelten nicht, 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.

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

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

  • 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.

  • 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.

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

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

  • 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 häufig verwendeten JCL-Rahmen sollten Sie allzu häufigen Gebrauch von Symbol-Ersetzungen vermeiden. Nehmen wir beispielsweise mal 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.