Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

Leistungsmessung und Tuning für Online-Transaktionsverarbeitung auf einer Mehrprozessoranlage:


01.07.1983 - 

Mit dem Gefühl allein ist nichts auszurichten

Mit der Verbreitung von Dialogsystemen steigt der Bedarf an Werkzeugen, mit denen sich gezielt Leistungsmessungen vornehmen lassen. Die Anwenderforderungen an ein System beinhalten hohe Verfügbarkeit, ständige Anpassunbfähigkeit und kurze Antwortzeiten trotz steigenden Durchsatzes. Mit geeigneten Softwarewerkzeugen lassen sich Größen wie Grenz- oder Zielauslastung kalkulieren.

Gesetzmäßigkeiten aus der Operationalen Analyse und der Warteschlangentheorie helfen hierbei dem Systemingenieur, ein optimales Tuning vorzunehmen. Erweiterte Möglichkeiten auf Mehrprozessorsystemen, bei denen sich mehrere unabhängige Prozessoren parallel einsetzen lassen, gewinnen unter diesem Aspekt für die Online-Transaktionsverarbeitung mit ihren konkurrierenden Aktivitäten auf einer Datenbasis immer mehr an Bedeutung. Die Ergebnisse aus Leistungsmessungen schließlich können dem EDV-Management wertvolle Hinweise über Umfang und Zeitpunkt notwendiger Investitionen geben.

Werkzeuge zur Leistungsmessung

Ließen sich früher Maßnahmen zur Systemverbesserung oft nur über den Daumen schätzen, so kann sich der Systemmanager heute auf eine Reihe von Werkzeugen stützen, die minutiös jeden Engpaß im System und damit jeden Grund für ein schlechtes Antwortzeitverhalten und ungenügenden Durchsatz aufdecken.

Solche Performance-Monitore sind umfangreiche Softwaretools. Entscheidend ist, daß die "Meßsonden" bereits tief in Hard-, Firmware und Betriebssystem verwurzelt sind und nicht im nachhinein auf ein bestehendes System aufgepfropft wurden. Nur auf diese Weise lassen sich exakte Informationen unmittelbar an der Quelle ermitteln, und der Aufwand hierfür bleibt vernachlässigbar gering. Er muß sich dennoch ermitteln lassen, indem sich der Monitor selbst mißt, um Verfälschungen durch die Messung selbst ausschließen zu können.

Komplizierter gewordene Einprozessorsysteme oder etwa moderne Mehrprozessoranlagen mit ihrer Vielzahl von Einzelkomponenten können heute unter keinen Umständen mehr auf solche Tools verzichten, mit "Gefühl" ist hier wenig auszurichten.

Für solche Leistungsmessungen die einerseits sicherstellen, daß vorhandene Betriebsmittel optimal eingesetzt sind,

die andererseits Fundamente liefern sollen für eine gesicherte Kapazitätsplanung, sind Tuningspezialisten nicht unbedingt notwendig. Tuning soll ja ein kontinuierlicher Vorgang sein, den der Betreiber der Anlage durchführen können muß, und nicht eine einmalige Feuerwehraktion vom Hersteller, wenn Probleme auftreten.

Im Gegenteil, ein Systemingenieur, der seinem Management Antwort auf Fragen geben soll, etwa "Wieso läuft das System denn in der letzten Zeit so schlecht?" oder "Setzen wir unsere vorhandene Hardware denn optimal ein?" oder auch "Schätzen Sie doch mal für unser zukünftig geplantes Durchsatzvolumen ab, ob die vorhandene Hardware reicht oder wenn nicht, welche Hardwarekomponenten werden voraussichtlich noch benötigt?", sollte ebenfalls vertraut mit dem Anwendungsdesign sein.

Eine Dialoganwendung beschreibt eine Menge nützlicher Arbeit, die mit Hilfe eines Computers erledigt wird. Die Arbeit verrichtet nicht ein Programm, sondern eine Reihe im Rechner ablaufender Programme (Prozesse), die hierbei andere Betriebsmittel (Systemressourcen) benutzen. Hierzu gehören nicht nur Hardwarekomponenten (CPU, Hauptspeicher, E/A-Kanäle, Plattenlaufwerke, Interprozessorkanalkopplungen), sondern auch Systemsoftwarekomponenten, die die Hardware steuern (Monitor, Hauptspeicherverwaltung, Gerätesteuerungsprogramme). So gesehen ist die Systemsoftware mit ihren einzelnen Betriebssystemfunktionen nicht getrennt, sondern als Bestandteil der Anwendung anzusehen.

Zu den Eigenschaften transaktionsorientierter Anwendungen, verallgemeinert für Mehrprozessorsysteme, die Leistungsverbesserungen ohne Umprogrammierung ermöglichen sollen, gehören:

- jeder Prozeß (ablaufendes System-oder Anwenderprogramm) kann in jeder Zentraleinheit laufen,

- jeder Prozeß kann in mehrfachen Kopien gleichzeitig ablaufen (Kontexfreiheit)

- die Last kann über alle Kopien ausgewogen verteilt werden (dynamischer Lastausgleich),

- jede Datei oder Teile von ihr, egal ob es sich um ein Programmobjekt oder einen Teil der Datenbank handelt, lassen sich auf jedes Plattenlaufwerk verlegen (Partitionierung und Verteilbarkeit),

- Vermeidung sequentieller Abhängigkeiten der Prozesse untereinander, damit die Nachrichtenwege einer Transaktion steuerbar bleiben.

Weshalb man auf die Einhaltung eines solchen "softwaretransparenten" Anwendungsdesigns beharren muß, wird aus den Gesetzmäßigkeiten der Operationalen Analyse deutlich.

Hat sich der Systemingenieur ein Bild gemacht, wie sich die Anwendung zusammensetzt, kann man die Transaktion, die auf dem Rechner ablaufen soll, in Einzelkomponenten aufteilen. Die Gesamtanforderung an Rechnerbetriebsmitteln (CPU, Platte, Leitung) läßt sich ausdrücken als die Summe der Anforderungen durch diese Teilkomponenten. Wieviel jedes Betriebsmittel pro Komponente zur Abarbeitung benötigt, ist mit Hilfe eines Performance-Monitors meßbar.

Tuningziel ist es, den Durchsatz des Systems, also die Anzahl der Transaktionen pro Sekunde, bei vernünftigen Antwortzeiten zu maximieren.

Es lassen sich folgende Zusammenhänge aufzeigen:

Belegung (Betriebsmittel) = Zeit innerhalb eines Intervalls, in dem das Betriebsmittel Service erteilt,

Auslastung (Betriebsmittel) = Belegung in einem Zeitfenster

Anforderung (Betriebsmittel) = Belegung pro Transaktion

Der Durchsatz ist eine Konstante, die sich aus der Auslastung eines beliebigen Betriebsmittels (BM) dividiert durch die Anforderung an dieses Betriebsmittel ergibt:

Ist beispielsweise die Auslastung der CPU 80 Prozent im betrachteten Zeitintervall von einer Sekunde, die Anforderung an CPU-Leistung 0,4 Sekunden pro Transaktion, so entspricht dies einem Durchsatz von zwei Transaktionen pro Sekunde.

Aus dieser Gesetzmäßigkeit zeigt sich unmittelbar, daß das oberste Tuningziel ist, gleiche Betriebsmittel gleich auszulasten, also auszubalancieren. Dagegen kann es kein Ziel sein, alle verschiedenartigen Betriebsmittel gleich zu belasten, da die Anforderung an unterschiedliche Betriebsmittel (CPU, Platte) in der Regel auch unterschiedlich sein werden.

Grenzon des Durchsatzes

Da die Auslastung eines Betriebsmittels nie mehr als 100 Prozent sein kann, ergeben sich physikalische Grenzen an den möglichen Durchsatz. Bleibt die Auslastung eines Betriebsmittels nie mehr als 100 Prozent sein kann, ergeben dich physikalische Grenzen an den möglichen Durchsatz. Bleibt die Auslastung eines BM konstant, kann der Durchsatz nur noch steigen, wenn die Anforderung in gleichem Maße sinkt.

Die Durchsatzformel zeigt damit unmittelbar den Engpaß im System an. Er wird verursacht durch das Betriebsmittel, bei dem das Verhältnis von Auslastung zu Anforderung am geringsten ist. Dies begrenzt den maximal möglichen Durchsatz.

Es wurden deshalb immer wieder von den einzelnen Rechnerherstellern Anstrengungen unternommen, die Anforderungen an die Betriebsmittel durch Verkürzung der Servicezeit (schnellere CPUs oder schnellere E/A-Kanäle) zu senken, um den möglichen Durchsatz zu erhöhen.

Parallel zu dieser Entwicklung ist zu beobachten, daß einzelne darüber hinaus dazu übergehen, nicht nur Plattengeräte oder Leitungskanäle, sondern auch entscheidende Betriebsmittel wie die zentralen Prozessoren einschließlich ihres Hauptspeichers zu vervielfachen.

Vorausgesetzt, die Anwendung läßt sich auf die Betriebsmittel verteilen, das heißt, man kann sie tunen gemäß den oben aufgestellten Forderungen, kennen solche modular ausbaubaren Mehrprozessorsysteme praktisch keine Durchsatzgrenzen mehr.

Neben dem Bemühen nach maximalem Durchsatz steht das Erreichen von vernünftigen Antwortzeiten in Dialogsystemen gleichrangig an oberster Priorität. Die Antwortzeit setzt sich aus Summe von Anforderung und Wartezeit vor jedem benötigten Betriebsmittel zusammen. Bei steigender Auslastung eines Betriebsmittels jedoch steigt die Wartezeit für alle weiteren Anforderungen überproportional stark an.

Man definiert deshalb sogenannte Zielauslastungen oder auch optimale Auslastung für die einzelnen Betriebsmittelarten.

In der Warteschlangentheorie entspricht dies dem Q-Faktor. Er beschreibt die maximale Auslastung eines Betriebsmittels, bei der die Warteschlange davor noch kontrollierbar ist. Ein Überschreiten führt zum überproportionalen Anwachsen der Wartezeit und damit der Antwortzeit.

Bei welcher Auslastung dieser kritische Punkt erreicht ist, hängt von der Verteilung der Transaktionsrate und der Bearbeitungszeit ab. Grob läßt sich sagen, daß bei einer Poisson-Verteilung als guter Richtwert etwa 60 Prozent angenommen werden kann, während bei konstanter Verteilung der Wert erheblich darüber, hingegen bei Stoßbelastung auch darunter liegen kann.

Aber die Zielauslastung wird nicht nur vom Q-Faktor, sondern auch von der überhaupt maximal möglichen Auslastung, der Grenzauslastung, vorgegeben. Bestimmte Betriebsmittel (Platten, Leitungen) können wegen sequentieller Abhängigkeiten bei der internen Verarbeitung eine Grenzauslastung von 100 Prozent in Theorie und Praxis nie erreichen.

Für die Grenzauslastung für ein Betriebsmittel gilt verallgemeinert:

Eine Platte kann in einem vorgegebenen Zeitintervall nur eine bestimmte Zeit Schreib- oder Leseoperationen durchführen. Teile der übrigen Zeit dienen auch bei voller Auslastung der Vorbereitung (Seck-operationen, Latency). Es läßt sich nur eine Grenzauslastung von vielleicht 40 Prozent erreichen.

Ein ähnliches Verhalten entsteht, wenn einzelne Anwendungsprozesse sequentiell voneinander abhängig gemacht werden (siehe Voraussetzung für tunebare Anwendung). Die

Grenzauslastung solcher Prozesse sinkt erheblich und damit der mögliche Durchsatz.

Ein Zielauslastung pro Betriebsmittel kann somit festgelegt werden als Produkt aus Q-Faktor und maximaler Geräteauslastung.

Hiernach ergeben sich für Platte und CPU bei gleichem Q-Faktor wesentlich unterschiedliche Zielauslastungen: Ist der Q-Faktor 0,6 und die Grenzauslastung der Platte 40 Prozent, so liegt die Zielauslastung für die CPU bei 60 Prozent, während sie bei der Platte nur 24 Prozent beträgt.

Kennt man die Auslastung der Betriebsmittel eines Rechners für typische Transaktionen, so läßt sich in Anbetracht dieser Gesetzmäßigkeiten das Verhalten eines Rechners in einer einfachen Formel beschreiben.

Statt für eine gegebene Hardwarekonfiguration und eine angenommene Last die Auslastung der Einzelkomponenten zu bestimmen, lassen sich bei Definition einer Zielauslastung unmittelbar die Anzahl benötigter Betriebsmittel bestimmen:

Es gilt:

Dies bedeutet beispielsweise für eine Anwendung mit einem geplanten Durchsatz von sechs Transaktionen pro Sekunde und einer CPU-Anforderung von 0,3 CPU-Sekunden pro Transaktion, daß drei CPUs bei konservativer Zielauslastung von 60 Prozent benötigt werden. Betragen die Anforderungen der Transaktion an weitere Betriebsmittel zusätzlich 0,7 Sekunden, so kann mit einer Antwortzeit von zwei bis 2,5 Sekunden gerechnet werden.

Ein Werkzeug, das dem Systemingenieur Einblick in die Anforderungen ermöglicht, die von den unterschiedlichen Anwendungs- und Systemkomponenten die einzelnen Betriebsmittel gestellt werden, ist beispielsweise Xray. Dieser von Tandem entwickelte Leistungsanalysator ermittelt den "working set", die durchschnittlichen Anforderungen an Speicher, bezogen auf einzelne Module oder einen ganzen Prozessor, macht verbrauchte CPU-Leistung insgesamt je Prozessor oder auch verfeinert bezogen auf einzelne Prozesse (ablaufende Programme) transparent oder mißt die Plattenauslegung unterteilt nach physikalischen Schreib-/Lesevorgängen und Seek-operationen. Die durch die Messung selbst verbrauchte CPU-Leistung läßt sich exakt messen und liegt unter einem Prozent.

Der Systemingenieur kann aus seinen Meßdaten Aufschluß über Betriebsmittelanforderungen und realisiertem Durchsatz gewinnen. Die Warteschlangen vor den einzelnen Betriebsmitteln lassen sich direkt für den Meßzeitraum oder ein Fenster hinein erkennen. So identifizierte Engpässe können durch gezieltes Verteilen beseitigt werden.

Einblick durch Xray

Die Ergebnisse fließen also unmittelbar in ein geeignetes Tuning ein und geben vor Inbetriebnahme neben der Funktionsfähigkeit im Streßtest Hinweise, ob das Antwortzeitverhalten zur gewünschten Akzeptanz beitragen kann.

Dadurch, daß jedes Betriebsmittel symbolisch adressiert werden kann, bleiben die Anwendungsprogramme durch die Maßnahme zur Ausbalancierung unverändert. Gleiches gilt, wenn bei Erhöhung des Durchsatzes die Grenzbelastung einzelner Betriebsmittelgruppen überschritten wird und das System modular erweitert werden soll.

Der Umfang solcher Erweiterungen läßt sich erheblich früher und exakter vorherbestimmen. Eine Kapazitätsplanung kann einerseits durch Hochrechnen eines geplanten Durchsatzwachstums mit den Kosten pro heutiger Transaktion oder aber unmittelbar durch verändertes Parametrisieren des Lastgenerators im Vorfeld ermittelt werden.

Die Aufgabe des Systemingenieurs kann sich also zunächst beschränken auf die Ermittlung von Betriebsmittelanforderung wesentlicher Einzelkomponenten der Transaktion, auf die Auslastung vorhandener Betriebsmittel und den Durchsatz.

Hat er diese Leistungsmessung mittels eines Performance-Monitors vorgenommen, bedeutet Tuning im wesentlichen Senkung der Betriebsmittelanforderungen und Ausbalancieren gleicher Betriebsmittel.

Lassen sich die Betriebsmittelanforderungen nicht mehr senken, so sind bei ausbalancierten Betriebsmitteln optimaler Durchsatz und bestmögliche Antwortzeit erreicht. Durch Ermittlung von den Kosten pro Transaktion läßt sich das Investitionsvolumen bei steigendem Durchsatz hochrechnen.

Sind die Antwortzeiten bei optimiertem Durchsatz nicht zufriedenstellend und keine weitere Senkung der Betriebsmittelanforderungen möglich, bleibt als Ausweg die Senkung des Durchsatzes oder die Erhöhung der Betriebsmittelkomponenten mit dem Ziel einer geringeren Zielauslastung.

Aber neben der Sicherstellung einer optimalen Dienstleistung der zur Verfügung stehenden Betriebsmittel erfüllen Leistungsmessung und Tuning zunehmend auch weitergehende Aufgaben.

Durch Einzelmessung von Transaktionen, die für die Akzeptanz beim späteren Anwender wichtig sind, lassen sich schon während der Designphase eines Dialogsystems Rückschlüsse auf zu erwartende Antwortzeiten unter späterer Last und die Anzahl von Systemkomponenten schließen, die zu einer vernünftigen Bewältigung der Last notwendig sind. Dies gibt dem Management wertvolle Hinweise auf das zu erwartende Investitionsvolumen, liefert eine Verknüpfung zwischen Anforderungen an das spätere System, zu erwartende Antwortzeiten und die Kosten hierfür (Kosten pro Transaktion).

Auch für die Kapazitätsplanung einer bestehenden Anwendung lassen sich exakte Zahlen ermitteln, wie sich steigende Anforderungen in Mark und Pfennig auswirken. Es läßt sich viel leichter ein EDV-Budget aufstellen und vertreten, wenn zu einem geplanten Anforderungsprofil die Auslastung der momentan verfügbaren Betriebsmittel hochgerechnet und notwendige Erweiterungen - falls nötig - in ihrem Umfang korrekt angegeben werden können.

Entscheidend aber für das Management wird wohl sein, daß die Investitionen sich in keinen Schritten gezielt nach dem tatsächlichen Bedarf richten können.

Diese Vorgehensweise aber ist nur sinnvoll vor dem Hintergrund einer softvaretransparenten Anwendung und einem Hardwarekonzept, welches beliebige Hardwareerweiterungen ohne Modellwechsel, ohne Softwareumstellung ermöglicht und die totale Verteilbarkeit von Betriebsmitteln in Abhängigkeit von ihren Anforderungen unterstützt.

Robert Zaster ist Systemingenieur bei Tandem Computers, Frankfurt.