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.

02.07.1982 - 

Engpässe beim Großrechnereinsatz durch analytische Konfigurationsplanung umgehen:

Leistungsplus durch Performance-Sicherung

MÜNCHEN - Performance ist kein Produkt, das von den Herstellern frei Haus geliefert wird, Performance muß vom Benutzer akribisch geplant, erarbeitet, überwacht und gepflegt werden. Zwar bemühen sich die DV-Verantwortlichen heute mehr denn je, jedes Bit aus ihren Maschinen "herauszukitzeln", aber häufig sind Kenntnisse über Grundlagen und Prinzipien von Performance-Analyse, - Messung oder -Planung nur unzureichend vorhanden.

Treten beim Austausch von Zentraleinheiten Performance-Probleme auf, ist meist eine mangelnde (fehlende) Anpassung der Arbeitslast an die Leistungsfähigkeit der CPU die Ursache. Oftmals wird übersehen, daß eine I/O-intensive Arbeitslast beim Einsatz einer doppelt so schnellen CPU noch I/O-intensiver wird, da Programme ihre I/O-Anforderungen dann in halbierten Intervallen stellen. Um schnelle Zentraleinheiten vernünftig auslasten zu können, ist dann eine Vielzahl extrem I/O-intensiver Programme nötig, was einerseits zu Engpässen von einzelnen Geräten führt und andererseits den vorgesehenen Hauptspeicher zu klein werden läßt, womit das System in den Seitenwechsel (Paging) treibt. Der Benutzer sollte sich klar darüber werden, daß zehn Prozent CPU-Leistung für Paging rund 300 000 Mark im Jahr kosten und dann eine entsprechende Hauptspeichererweiterung dagegen rechnen.

Wird etwa eine I/O-intensive Arbeitslast von zwei IBM 3033U auf eine IBM 3081D gelegt, sind umfangreiche Vorkehrungen im E/A-Bereich notwendig, um eine gute Performance zu erreichen. Dabei sind die beiden Performance-Kriterien Systemdurchsatz und Zeitverhalten einzelner Programme von besonderem Interesse.

Einige Berechnungsbeispiele sollen demonstrieren, wie wichtig Ordnung im E/A-Bereich für die Performance ist und wie sich Durchsatz und Zeitverhalten beim Einsatz einer doppelt so schnellen CPU verhalten. Dabei wird von einfachen Voraussetzungen ausgegangen. Es wird unterstellt, daß Batch-Programme ihre I/O synchron abwickeln und einen I/O-Puffer benutzen. Bei Batch-Programmen führt diese Betrachtungsweise jedoch bei Rechenergebnissen zur minimalen CPU-Intensität und -zur längeren Alleinlaufzeit (worst case), während sie bei TP-Anwendungen realistische Ergebnisse liefert.

Diese Formeln kommen zum Einsatz:

Verursachte eine Transaktion auf einer 3033U 30 CPU-Zeit (zirka 150 000 Instruktionen) und 10 I/O mit einer mittleren Hardwarebedienzeit von jeweils 25 ms, ergibt sich eine Systembedienzeit von 280 ms. Reduziert sich die CPU-Zeit um 50 Prozent (wegen doppelter CPU-Leistung) verringert sich die Systembedienzeit um nur 5,4 Prozent auf 265ms. Das Programm, das diese Transaktion bearbeitet, kann maximal 3,57 Transaktionen pro Sekunde auf einer 3033U und maximal 3,77 TR/s auf einer 3081U (+ 5,6 Prozent) bewältigen.

Wenn sich beim Betrieb der 3081D jedoch Engpässe im E/A-Bereich ergeben (speziell bei Magnetplattengeräten) und sich die einzelne I/O nur um 5 ms verzögert, bedeutet dies eine Erhöhung der Systembedienzeit um 18,9 Prozent sowie eine Verschlechterung gegenüber der 3033U um 12,5 Prozent und einen Durchsatzverlust von 11,2 Prozent.

Bei Batch-Programmen lassen sich ähnliche Betrachtungen anstellen. Verursacht ein Batch-Programm auf einer 3033U etwa 500 I/O je CPU-Sekunde (User-Mode) und eine Millisekunde CPU-Zeit (System-Mode) je SIO (Start I/O), ergibt sich bei 25 ms Bedienzeit je I/O eine Alleinlaufzeit von 1000 ms User-CPU + 500 ms System-CPU + 12 500 ms I/O-Zeit =14 000ms für die Abwicklung von 500 I/O-Operationen bei einer CPU-Intensität des Programmes von 1500 ms CPU-Zeit x 100/14 000 ms = 10,71%

Daraus folgt ein vertretbarer Multi-Programming-Grad (MPL) von 9,33, das heißt, 9,33 simultan ablaufende Programme diesen Typs würden die Zentraleinheit zu 100 Prozent auslasten.

Die Übernahme eines solchen Programmes auf eine 3081D würde zu einer Alleinlaufzeit von 500 ms User-CPU + 250 ms System-CPU + 12 500 ms I/O-Zeit = 13 250 ms führen und zu einer CPU-Intensität von 5,66 Prozent. Eine Erhöhung des MPL auf 17,66 würde zu einer 100prozentigen Auslastung der CPU führen. Das bedeutet eine Steigerung des MPL um 89,4 Prozent, aber keine Verdoppelung!

Zeitverhalten und Durchsatz

Die bisherigen Berechnungen zeigen, obwohl sie auf stark vereinfachenden Annahmen beruhen, sehr deutlich die Tendenzen, wie sich Zeitverhalten und Durchsatz einzelner Programme beim Einsatz auf leistungsfähigeren Zentraleinheiten verhalten werden. Deutlich wird auch, daß der MPL, also die Anzahl gleichzeitig ablaufender Programme, erhöht werden muß, wenn eine Arbeitslast unverändert auf dem leistungsfähigeren System zum Einsatz kommt, um die Zentraleinheitsleistung wirksam zu nutzen.

Am Beispiel der Auswirkungen der Erhöhung von Blockungsfaktoren soll gezeigt werden, daß Zeitverhalten und Durchsatz von Programmen durch eine Anpassung an die Leistungsfähigkeit der CPU gravierend verbessert werden können.

Eine Verdoppelung der Blockungsfaktoren führt zu einer Erhöhung der CPU-Intensität der betroffenen Programme, zu einer Reduzierung des Systemaufwandes zur Bearbeitung einzelner I/O um 50 Prozent und zu einer erheblichen Verknüpfung der Laufzeiten.

Wirkung von Blockungsfaktoren

Gleichzeitig erhöht sich die Kanalauslastung und der Hauptspeicherbedarf der Anwendungen. Da aber der MPL, der zur Auslastung der CPU notwendig ist, niedriger wird, ergibt sich nur bei mangelnder Arbeitslastplanung ein negativer Einfluß auf den Seitenwechsel.

Am Beispiel des bereits berechneten Batch-Programmes soll die Wirkung von Blockungsfaktoren noch einmal verdeutlicht werden.

Beim Einsatz dieses Programmes auf einer 3081D ergaben sich 1000 I/O je CPU-Sekunde (User-Mode) und 0,5 ms System-CPU-Zeit je SIO. Werden Blockungsfaktoren nun verdoppelt, reduziert sich die I/O-Anzahl auf 500, wobei jede einzelne I/O wegen des übertragenen höheren Datenvolumens eine Bedienzeitverlängerung um 1,5 ms auf 26,5 ms erfährt. Dies ergibt nun eine Alleinlaufzeit zur Bearbeitung des gleichen Datenvolumens von 1000 ms User-CPU + 250 ms System-CPU + 13 250 ms I/O-Zeit = 14 500 ms und eine CPU-Intensität von 8,62 Prozent sowie einen auf 11,6 reduzierten MPL. Die Alleinlaufzeit zur Bearbeitung von 1000 I/O verkürzt sich von 26,5 auf 14,5 Sekunden (- 45,3 Prozent).

Sparsam mit I/O-Operationen

Dieses Beispiel zeigt, daß es in der Hand der Benutzer liegt, welche Performance ihr System erreicht. Daß man bei Dialoganwendungen Blockungsfaktoren nicht so ohne weiteres erhöhen kann, ist dabei unerheblich. Man kann in jedem Fall dafür Sorge tragen, daß I/O-Operationen mit größter Sparsamkeit angestoßen werden, daß Daten so strukturiert werden, daß sie nur verarbeitungsrelevant transportiert werden. Eine höhere Produktivität einzelner I/O erhöht schließlich auch die CPU-Intensität der Anwendungen. Denn Jumbos sind für CPU-intensive Anwendungen prädestiniert.

16 Kanäle sind bei dieser Arbeitslast noch längst kein Engpaß. Wenn ein Programm 500 I/O in 14,5 Sekunden bearbeitet, fordert es je Sekunde 34,5 I/O vom System. Bei einem vernünftigen MPL von 11,6 muß das System etwa 400 I/O je Sekunde leisten. Das bedeutet 25 I/O je Kanal wenn das System ausgewogen gefahren wird. Bei einer durchschnittlichen Blocklänge von 4 KB wird ein Kanal somit zu zirka 3,4 Prozent ausgelastet. Ein Disc-Controller mit einer Übertragungsleistung von 1,2 MB/s arbeitet somit bei 25 I/O je Sekunde mit einer Auslastung von zehn Prozent.

Engpässe frühzeitig einkreisen

Beim Umstieg auf Zentraleinheiten mit größerer Leistung empfiehlt es sich, die CPU-Intensität der Anwendungen zu erhöhen. Ein verstärkter Einsatz von höheren Blockungsfaktoren, asynchroner I/O und eine höhere Produktivität einzelner I/O ist notwendig, um eine zufriedenstellende Performance zu erreichen. Selbstverständlich sollten auch überflüssige I/O, wo nur immer möglich, abgebaut werden. Kanäle sind selten ein Engpaß. Auch der Hauptspeicher muß nicht zum Engpaß werden, wenn der MPL in einem vernünftigen Rahmen bleibt.

Die gezeigten Berechnungen zählen zu den grundlegendsten überhaupt. Um beim Einsatz einer neuen Zentraleinheit nicht von einer unbefriedigenden Performance überrascht zu werden, empfiehlt sich die analytische Modellierung des DV-Systems. So können eventuelle Engpässe frühzeitig erkannt und im Rahmen der Arbeitslastanpassung und der Konfigurationsplanung berücksichtigt werden.

*Claus Weichselbaumer arbeitet als selbständiger Unternehmensberater in München und ist Spezialist für Performance-Fragen und Kapazitätsplanung.