Dieser Abschnitt enthält allgemeine Ratschläge bei leistungsrelevanten Problemen im Zusammenhang mit dem Buffer Pool und den BP Cache.
Erläuterungen zu den in diesem Abschnitt genannten Statistikelementen finden Sie unter Buffer Pool Load/Locate-Statistiken.
Dieses Kapitel behandelt die folgenden Themen:
Wenn innerhalb einer Natural-Sitzung ein Natural-Objekt erstmalig referenziert wird, erstellt der Buffer Pool Manager einen Verzeichniseintrag für dieses Objekt. Ein Verzeichniseintrag dient zur Identifizierung eines Objekts und enthält Informationen wie den Namen des Objekts, die Library, in der es sich befindet (Name, Datenbankkennung und Dateinummer) und die Adresse des Objekts (Position) im Buffer Pool.
Das Natural-Laufzeitsystem speichert die Namen der Objekte, die kürzlich ausgeführt wurden, die Libraries (Name, Datenbankkennung und Dateinummer), in denen sie sich befinden, und (zur Schnellsuche) die Adressen der entsprechenden Buffer Pool-Verzeichniseinträge in der internen Fast-Locate-Tabelle für die Dauer einer Natural-Sitzung.
Wenn ein Benutzer ein Objekt aufruft, das zuvor in der Natural-Sitzung verwendet wurde, gibt das Natural-Laufzeitsystem die Informationen aus der internen Fast-Locate-Tabelle an den Buffer Pool Manager weiter, der dann die normale Lokalisierungsprozedur (Normal Locate) umgehen und einen zeitsparenden Schnellsuche-Aufruf (Fast Locate) durchführen kann (siehe Quick Locate Calls). Dies ist der effizienteste Weg, um ein Objekt zu lokalisieren.
Wenn sich die Position eines Objekts im Buffer Pool geändert hat, plant der Buffer Pool Manager automatisch einen Normal Locate-Aufruf. Die Position ändert sich in der Regel, wenn ein Objekt, das aus dem Buffer Pool gelöscht oder durch ein anderes Objekt überschrieben wurde, erneut in den Buffer Pool geladen wird.
Die interne Schnellsuche-Tabelle enthält maximal 128 Einträge. Die
Schnellsuche-Tabelle wird mit dem Systemkommando
LOGON (Anmelden) zurückgesetzt und muss mit Normal
Locate-Aufrufen erneut gefüllt werden. Daher verliert eine Anwendung, die ein
LOGON durchführt, an Leistung.
Ein hohes Verhältnis von
Normal Locate
Calls zu Quick Locate
Calls deutet auf die Verwendung von
LOGON-Kommandos in einer Natural-Anwendung hin, da
jedes LOGON ein Zurücksetzen der internen Fast
Locate-Tabelle bewirkt.
Wenn der Profilparameter BPSFI (Objektsuche
zuerst im Buffer Pool) auf OFF gesetzt ist, kann das folgende
Szenario zu unerwarteten Ergebnissen führen:
Die Liste der Steplibs enthält die Libraries S1 und S2, wobei S1 vor S2 durchsucht wird.
Während der aktuellen Natural-Sitzung wird auf ein Objekt aus S2 zugegriffen.
Eine andere Natural-Sitzung kopiert eine neue Version dieses Objekts in S1.
Wird dann während der aktuellen Sitzung (ohne neues
LOGON) erneut auf dieses Objekt zugegriffen, wird
die neue Version des Objekts nicht verwendet.
Beachten Sie Folgendes, um solche unerwarteten Suchergebnisse zu vermeiden:
Setzen Sie ein LOGON-Systemkommando
ab.
Da ein LOGON-Kommando in einer Client/Server-Umgebung nicht abgesetzt werden kann, können Sie die Anwendungsprogrammierschnittstelle (API) USR3004N verwenden, um die Fast-Locate-Tabelle zu löschen.
Weitere Informationen zur Verwendung von APIs finden Sie in der Beschreibung des Dienstprogramms SYSEXT.
Wenn BPSFI=ON gesetzt ist, sollten Objektnamen in
allen Libraries, die an Objektsuchoperationen beteiligt sind, immer eindeutig
sein. Damit ist auch gewährleistet, dass solche Szenarien nicht auftreten.
Die Suche nach einem Natural-Objekt in einer langen Kette von Steplib-Libraries hat einen negativen Einfluss auf die Performance.
Für jede Steplib ruft die Natural-Laufzeit den Buffer Pool Manager auf, bis das gesuchte Objekt gefunden wird. Jeder unnötige Aufruf einer Steplib-Library, die das angeforderte Objekt nicht enthält, kann jedoch normalerweise vermieden werden.
Abhängig von der Einstellung des Profilparameters
BPSFI
(siehe Parameter-Referenz-Dokumentation) können
zusätzliche Datenbankaufrufe erforderlich sein.
Eine lange Steplib-Kette zeigt sich durch ein hohes Verhältnis von Normal Locate Calls (einschließlich Steplib-Suchen) zu Normal Locate Calls (ohne Steplib-Suchen), das wie folgt berechnet wird:
Normal Locate Calls: (Normal Locate Calls - STEPLIB Searches)
Beim Durchsuchen der Standard-Steplib-Kette (Library SYSTEM von FUSER, Library SYSTEM von FNAT) führt jeder Versuch, ein Objekt aus SYSTEM (FNAT) zu laden, zu Folgendem:
3 Normal Locate Calls und 2 STEPLIB Searches
Erläuterung:
3 Normal Locate-Aufrufe resultieren aus
Suchen in der aktuellen Library, der Library SYSTEM (FUSER) und der Library
SYSTEM (FNAT). Es gibt (mindestens) 2 Normal Locate-Aufrufe, die fehlschlagen,
da das Objekt weder in der aktuellen Library noch in der Library SYSTEM (FUSER)
gespeichert ist. Bei Anwendung der obigen Formel ergibt sich ein Verhältnis von
3:1.
Befindet sich das Objekt in der aktuellen Library, ist das Ergebnis wie folgt:
1 Normal Locate Call und 0 (Null) STEPLIB Searches.
Bei Anwendung der obigen Formel ergibt sich ein Verhältnis von 1:1.
Eine Anwendung, die viele Natural-Objekte enthält, wobei jedes Objekt nur selten ausgeführt wird, hat starke Auswirkungen auf die Leistung des Buffer Pool. Keines der Objekte verbleibt lange im Buffer Pool und viele Objekte müssen aus einer Systemdatei geladen werden. Aus Performance-Gründen sollte eine Anwendung Objekte so oft wie möglich wiederverwenden, z. B. indem sie identischen Quellcode, der in mehreren Objekten enthalten ist, in ein einziges Objekt verschiebt.
Sie können die Verwendung von Objekten mit der Funktion überprüfen (siehe Abschnitt Objekte auflisten). Die Spalte Max enthält z.B. Informationen über die maximale Anzahl von Anwendungen, die ein Objekt ausgeführt haben, und die Spalte TotalUC enthält die Gesamtzahl der Locate-Aufrufe eines Objekts, das in den Buffer Pool geladen wurde.
Objekte können einzeln mit der Funktion oder durch Angabe in einer Preload-Liste resident gemacht werden (siehe Preload-Liste verwalten).
Es gibt keine allgemeinen Empfehlungen, wann ein lokaler oder ein globaler Buffer Pool verwendet werden sollte, da verschiedene Anwendungen unterschiedliche Anforderungen haben. Aufgrund von Erfahrungswerten können wir jedoch allgemeine Ratschläge geben:
Die Performance kann durch die Verwendung mehrerer kleiner lokaler Buffer Pools anstelle eines einzigen globalen Buffer Pools verbessert werden, wenn die lokalen Buffer Pools verschiedenen Anwendungsumgebungen zugewiesen werden können.
In CICS-Umgebungen beispielsweise verbessert sich die Leistung in der Regel durch die Verwendung eines lokalen Buffer Pools für jede AOR (Application Operating Region).
Bei verschiedenen Batch-Anwendungen, die auf die gleichen Natural-Objekte verweisen, kann sich die Performance verbessern, wenn diese Anwendungen einen gemeinsamen globalen Buffer Pool anstelle eines lokalen Buffer Pools für jede einzelne Anwendung verwenden. In diesem Fall ist die Wahrscheinlichkeit höher, dass die von jeder Anwendung benötigten Objekte bereits von einer der anderen Anwendungen in den globalen Buffer Pool geladen wurden.