SCHENEFELD (je) - Generelle Standards für die Messung der Leistungsfähigkeit von IBMs Information Management System (IMS) gibt es nicht. Wer eine solche Messung vornehmen will, muß die im jeweiligen Einzelfall geltenden Performance-Faktoren und -Ziele definieren, um auf diese Weise ein gezieltes Tuning und damit letztlich befriedigende Antwortzeiten zu erreichen. Hans-Werner Steffen von der Schenefelder Information Systems GmbH gibt dem Systemprogrammierer in dieser und der folgenden Ausgabe der COMPUTERWOCHE Hinweise zur IMS-Optimierung.
Die Auswahl der maßgeblichen IMS-Performance-Faktoren wird durch die Umgebung, in der IMS gefahren wird, bestimmt. Die relative Bedeutung von Kosten und Verfügbarkeit der Hardware, die Geschwindigkeit der Entwicklung und der Wartung sowie die Unternehmensziele bei der Benutzung von IMS bestimmen das Abwägen zwischen der Mittelausnutzung und der Zeit. Das ist das zentrale Problem aller Software-Optimierungsversuche.
Die Bestimmung von Performance-Zielen bedeutet für den IMS-System-Designer die Erstellung einer Matrix zur Auswahl der vielen verfügbaren Systemparameter sowie der Festlegung einer kostenmäßigen Auswirkung der zukünftigen Änderungen eines laufenden Systems.
Um ein IMS-System optimal zu führen, sind vier Hauptfunktionen unerläßlich.
Die erste Hauptfunktion ist das Design: der Entwurf der Datenbank, der Anwendungen sowie der Wartung des laufenden Systems. Die Erstellung eines Kriterienkataloges als zweite Hauptfunktion enthält die Festlegung der Leistungskriterien des Systems bezüglich der Hardware, der Zugriffszeit auf die Datenbank und die ungefähre Antwortzeit (Response Time) der Transaktionen.
Der Aufbau der Datenbank als dritte Hauptfunktion beginnt sofort anschließend an das Design unter Berücksichtigung des Kriterienkataloges insbesondere bezüglich der in der Datenbank benötigten Zeiger. Die Implementierung einer Datenbank kann dann ohne Verzögerung erfolgen.
Sehr oft wird die vierte Phase, das Monitoring, vergessen oder zurückgestellt, weil der Druck auf die EDV-Abteilung zur Durchführung der zweiten Funktion sowie der erforderlichen Anwendungssysteme dazu zwingt. Diese Hauptfunktion wird meist erst dann durchgeführt - wenn überhaupt -, wenn das gesamte Dialogsystem bereits realisiert ist.
In der Praxis ist es jedoch so, daß der Anwender nach Realisierung der dritten oder vierten Anwendung feststellt und bemängelt, daß das System nicht so schnell antwortet, wie ursprünglich geplant. Zu diesem Zeitpunkt beginnt der Systemprogrammierer die Leistung des IMS-DC-Systems zu überprüfen und die Poolgrößen so zu verändern, daß der erhöhte Arbeitsanfall durchgeführt werden kann.
Notbehelf: Poolgrößenveränderung
Wenn dieses Ziel erreicht ist und die Beschwerden der betroffenen Fachabteilung abklingen, kann normalerweise der Systemprogrammierer sein eigentliches Ziel, die Installation des neuesten Betriebssystem-Releases oder des IMS-Releases, durchführen. Das IMS läuft zu aller Zufriedenheit so lange, bis neue Aktivitäten und Anwendungen zu erneuten Reklamationen der Anwendungsabteilungen führen.
Jetzt ist es meistens jedoch nicht mehr möglich, einfach die Poolgrößen zu verändern, um den neuen Anforderungen gerecht zu werden. Im Gegenteil: Jetzt werden detaillierte Messungen der Leistungsfähigkeit des IMS-Systems erforderlich. Unglücklicherweise müssen der Systemprogrammierer und sein technischer Berater jetzt ein krankes System analysieren und feststellen, wie die Leistung dieses Systems in den letzten Wochen oder Monaten gewesen ist, um die Gründe für einen Abfall der Antwortzeiten festzustellen.
Normalerweise ist das der Zeitpunkt, an dem eine detaillierte Analyse durchgeführt wird, denn mittlerweile behaupten die Anwender, daß das System entweder unzuverlässig ist oder die EDV-Abteilung nicht in der Lage ist, es zu managen. Aus diesem Zwang heraus versucht die EDV-Abteilung, das IMS regelmäßig zu überprüfen. Man möchte so schnell wie möglich alle Leistungsstatistiken auf einmal durchführen. Da eine gut dokumentierte Methode der statistischen Datensammlung meist nicht vorhanden ist, führt das zu einem ständigen Verlust von Monitoring/Tuning-Zyklen.
1) Anzahl Trans./Sek. (A) bei einer durchschnittlichen Antwort von Ta Sekunden
2) Durchschnittliche Antwortzeit (Tb) bei R Transaktionen
3) Maximale Trans./Sek. (M) bei endlichen Queues
4) Prozentualer Anteil der Transaktionen mit einer geringeren Antwortzeit als Ty bei Y Trans./Sek.
Unter dem Gesichtspunkt dessen, was der technische Berater benötigt, und den Beispielen zufälligen Monitorings wird nun erkannt, daß ein laufendes Monitoring sich auf die Daten beziehen sollte, die gestern geladen und verarbeitet wurden. Von großer Wichtigkeit sind ebenfalls die heutigen anomalen Bedingungen. Besteht andererseits ein Verständnis für die internen Funktionen des IMS, so sollte es nicht schwierig sein, eine Diagnose der Probleme und eine entsprechende effektive Lösung zu erzielen.
Nachdem jetzt deutlich geworden ist, daß das ständige Monitoring eine Grundvoraussetzung ist, können wir nun den Fluß einer Transaktion durch das System verfolgen, um die Hauptkomponenten des IMS sowie die Auswirkungen dieser Komponenten auf die gesamte Antwortzeit verstehen.
Die Einheit, durch die die meisten IMS-Systeme gemessen werden, ist die "Transaktion" das heißt, die Zeit von der Eingabe einer Nachricht bis zum Empfang einer oder mehrerer Ausgabenachrichten als Antwort. Im Falle des Dialoges handelt es sich dabei um einen Schritt einer solchen Transaktion. Das Hauptziel jeglicher Tuningaktivitäten ist es, eine Transaktion so schnell wie möglich unter Verwendung möglichst geringer Mittel wie Zeit, CPU-Zyklen oder Ein-/Ausgabe-Einheiten durch das System zu schleusen.
Wird die Leistungsfähigkeit des IMS-Systems unter dieser Voraussetzung untersucht, dann müssen zwei Fragen beantwortet werden: "Welche Transaktionen beeinflussen am meisten die Basis-Systemmittel?" und "Welche Systemkomponenten beeinflussen am meisten die einzelne Transaktions-Antwortzeit?".
Diese beiden Fragen können zu der Hauptfrage zusammengefaßt werden, die es erlaubt, das Hauptziel des System-Monitoring zu definieren: "Wie reagiert das System unter einem gegebenen Transaction-Load?"
Der Weg einer Transaktion durch das System wird in der folgenden Aufstellung dargestellt. Diese Aufstellung zeigt die IMS-Libraries und -Queues sowie den Buffer Pool zusammen mit den grundsätzlichen Einflüssen auf jede Transaktion bezüglich der Antwortzeit auf jeder Stufe des Systems. Wird der Transaktionsfluß verfolgt dann wird ersichtlich, welche Daten für die speziellen Monitoring-Stufen gesammelt werden müssen.
Nachdem der Benutzer an seinem Terminal die Daten-Eingabe-Taste betätigt hat, muß er warten, bis die Datenfernverarbeitungs-Zugriffsmethode sein Terminal pollt. Während andere Terminals an derselben Leitung gepollt werden, tritt immer eine Verzögerung auf. Lange Verzögerungen erfolgen immer dann, wenn ein anderes Terminal an derselben Leitung bereits Daten in das System überträgt. Wegen der Beschränkungen benutzter Softwaremonitore ist es unmöglich, diese Verzögerungen aufzuzeichnen, da die Monitore nicht wissen, wann der Operator die Daten-Eingabe-Taste betätigt.
Ist die vom Bildschirm eingegebene Nachricht in das System übertragen, dann wird sie durch das Feature MFS-Message Format Service verarbeitet und anschließend durch den Message Queue Handler in die Eingabe-Warteschlange gestellt.
Die Anzahl der für den Formatbereich generierten I/Os jeder individuellen Transaktion kann festgestellt werden. Darüber hinaus werden weitere allgemeine Informationen über die Aktivitäten innerhalb der verschiedenen Buffer Pools benötigt, da die Haupteinflüsse auf die Verzögerung durch die MFS-Verarbeitung, die aktuelle Größe der Pools sowie die Lage des Überlaufbereiches für Warteschlangen bestimmt werden.
Message Queue Pool
Errechnen der Pooleffizienz:
1-(Anzahl READs + Anzahl WRITEs)/(Gesamt CALLs QMGR)
Errechnen der Platten-I/Os je Nachricht:
1-(Anzahl READs + Anzahl WRITEs)/(Anzahl ENQs)
Um die Nachricht verarbeiten zu können, muß sie nun zunächst in die MPR-Message Processing Region gestellt werden. In einem stark belasteten System kann diese Wartezeit eine Hauptkomponente der Antwortzeit sein. Daher ist es außerordentlich wichtig, die Region-Belegung einer jeden Message-Region zu messen. Um die Region-Belegung sowie die korrespondierende Wartezeit in der Warteschlange zu reduzieren, muß die Programmladezeit und die Ausführungszeit verringert werden.
Ist die Notwendigkeit des Monitoring der Region-Belegung erkannt, sollten die Gegebenheiten untersucht werden, die durch das Class Scheduling beeinflußt werden. Während des Monitoring werden wir feststellen, daß Message-Regions unbenutzt sind, während Nachrichten noch in der Eingabe-Warteschlange warten. In diesem Fall sollte überlegt werden, ob durch eine Neuzuordnung der Scheduling-Classes zu den wartenden Transaktionen eine Verbesserung erzielt werden kann.
Ein ähnlicher Effekt kann durch den dem PSB-Pool und dem DMB-Pool zugeordneten Speicher auftreten. Jeder Hinweis darauf, daß der DMB-Pool zu klein ist, sollte sofort beachtet werden, da der enorme Overhead der DB-Close- und -Open-Routine immer dann zum Tragen kommt, wenn ein DMB vom Pool vorübergehend ausgelagert wird.
Ist eine Transaktion gescheduled, kann eine weitere lange Verzögerung auftreten, bevor die Kontrolle an das Programm übergeben wird. Diese Zeit entsteht durch das Auffinden des Programmes in die Programmbibliothek, nachdem verschiedene verkettete Library Directories durchsucht und das Programm in die Region geladen wurde, und schließlich durch die Programminitialisierung. Dies ist ohne Zweifel der wichtigste Punkt.
Zur Überprüfung der Region-Belegung muß die Ausführungszeit jedes Nachrichtenverarbeitungsprogrammes in Verbindung mit der Anzahl der Schedulings in jeder Region festgestellt werden sowie die Anzahl der verarbeiteten Transaktionen durch jedes Schedule. Weiterhin werden die Anzahl der DL/1 Calls je Transaktion und die Anzahl der Platten-I/Os je Transaktion benötigt.
Wird fortgesetzt
Dipl.-Kfm. Hans-Werner Steffen ist Marketing-Leiter in der Hamburger Geschäftsstelle der Information Systems GmbH, Schenefeld. Information Systems ist ein unabhängiges deutsches Beratungsunternehmen, das EDV-Dienstleistungen in folgenden "Service-Bereichen" anbietet: Projektmanagement, Anwendungsprogrammierung, Rechenzentrumsorganisation, Training, Datenmanagement und DB/DC. Zum Bereich DB/DC gehören Entwurf und Implementierung von Datenbanksystemen, Auswahl von Datenbankmanagement-Systemen und DFÜ-Monitoren sowie das Tuning von Datenbankmanagement-Systemen.