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.

31.10.1975 - 

Arbeitslast-Berechnung von Realzeit-Systemen

Messen, Zählen und Schätzen kombiniert

MÜNCHEN - Bei der Konzeption von Realzeit-Systemen sind klare Vorstellungen über die Belastung der Anlage außerordentlich wichtig. Eine zu engherzig ausgelegte Hardware muß zu untragbaren Reaktionszeiten führen. Auf der anderen Seite werden viele Anlagen nur für ein einziges System installiert; dann aber ist ein Zuviel an Leistungsfähigkeit hinausgeworfenes Geld.

Besonderheiten bei Realzeit-Systemen

Die Vorgehensweise zur Arbeitslast-Abschätzung ist bei Realzeit-Systemen eine völlig andere als bei der Planung eines normalen Rechenzentrums.

Gewöhnlich hat ein Rechenzentrum einen Jobmix aus sehr vielen Programmen zu bewältigen, über die mehr oder weniger exakte Belastungsaussagen existieren:

- Häufigkeit der Läufe

- CPU-Zeiten

- Art und Anzahl der Externzugriffe

- Prioritäten

- Speicherbedarf

Welche Funktionen die Programme im einzelnen wie ausführen, wird man

dagegen kaum analysieren wollen. Man muß, wenn es an die Planung der

Hardware geht, sehr konkrete Vorstellungen über die Struktur und innere Funktion des Systems besitzen. CPU-Last, E/A-Aktivitäten und Response-Zeit sind dagegen Größen, die - in Abhängigkeit von einer vorgegebenen äußeren Belastung (Mengengerüst) - zu ermitteln sind.

Simulation oder analytische Verfahren

Eine elegante und präzise Technik, die mit der Auslegung verbundener Fragen zu klären, ist die Durchführung einer Simulation. Man kann jedoch auch mit weniger Aufwand zu wertvollen Ergebnissen kommen, wenn man rechnerisch eine Arbeitslast-Abschätzung durchführt. Die zu erwartende mittlere CPU-Auslastung in Spitzenzeiten ist eine der wichtigsten zu ermittelnden Größen.

In Abbildung 1 ist ein elementarer Zusammenhang dargestellt, wie er sich jedem Lehrbuch der Warteschlangen-Theorie findet. Die Kurve gibt an, wie lange - in Abhängigkeit von der mittleren CPU-Auslastung - die Warteschlangen der Tasks vor (einzigen) CPU zu erwarten ist.

Beispielsweise ist bei einer Auslastung von 70% eine Wartezeit zu erwarten, die etwa 2,3mal so hoch ist, wie die (als konstant angenommene) reine Bearbeitungszeit der Task ist. Bei 80% Auslastung steigt die Wartezeit schon auf das 4fache, bei 90% auf das 9fache der Bearbeitungszeit. D. h., eine Auslastung von mehr als 70 - 80% ist bei einem Realzeit-System praktisch indiskutabel.

Diese Wartezeiten dürfen natürlich nicht mit den Responsezeiten des Systems verwechselt werden, die ja auch ganz wesentlich von den E/A-Zugriffen abhängen. Hier können bekanntlich ganz ähnliche Warteschlangen-Probleme auftreten.

Grundverfahren der Analyse

Einer Abschätzung der Arbeitslasten kommt ein modularer Aufbau des Systems sehr entgegen. Aufgrund eines vorgegebenen Mengengerüsts ist es relativ nicht abzuschätzen, Wie häufig die einzelnen Moduln durchlaufen werden. Man braucht daher "nur noch" zu ermitteln, wie stark jeder Modul die CPU belastet. Für die ermittlung der Laufzeiten der Moduln gibt es prinzipiell 3 Möglichkeiten:

- messen

- analysieren und auszählen

- schätzen nach Erfahrung.

Messen ist selbstverständlich die sicherste Methode, stößt aber auf leichte Schwierigkeiten, da die Programme noch nicht existieren. Auszählen, d. h. eine Detailanalyse, die die innere Schleifenstruktur und den Befehlsaufbau berücksichtigt, ist sehr aufwendig. Dafür kann man fast die Programme schreiben. Schätzen nach Erfahrung und durch Vergleich mit ähnlichen Programmen geht schnell, ist aber außerordentlich unzuverlässig. Häufig wird man um ein Mehrfaches nach unten oder oben danebenliegen - sicherlich keine gute Voraussetzung für eine saubere Systemplanung.

Daß dennoch eine Kombination der drei Methoden zu sehr vernünftigen Ergebnissen führt, hat sich in der Praxis gezeigt.

Iteratives Vorgehen

Zunächst wird man für jedes Modul grobe Laufzeitabschätzungen - möglichst durch mehrere Leute unabhängig - durchführen. So erhält man einen ersten Anhaltspunkt.

Nun multipliziert man die geschätzte Durchlaufzeit bzw. die Anzahl der abzuarbeitenden Maschinenbefehle, mit der erwarteten Aufrufhäufigkeit pro Zeiteinheit und errechnet für jeden Modul den prozentualen Anteil an der, Gesamt-CPU-Last.

Ein typisches Ergebnis ist insgesamt 50 Moduln der Löwenanteil der Laufzeit in ganz wenigen vielleicht 10 Moduln, verbraten wird. Alle anderen liefern Beträge von zusammen unter einem oder zwei Prozent. Daran ändert sich auch prinzipiell nicht viel, wenn die Groblaufzeit-Schätzung bei einigen, sagen wir um 500% danebenliegt.

Bei all diesen, die CPU wenig belastenden Moduln, gibt man sich mit der Abschätzung bereits zufrieden. Der Fehler wird im übrigen nicht als so gravierend ausfallen, da sich die Schätzfehler weitgehend gegenseitig aufheben.

Für die wichtigeren Moduln geht man nun einen Schritt weiter: Man analysiert die Schleifenstruktur und zerlegt den Modul in Routinen, die nur noch eine begrenzte Funktion umfassen. Völlig analog zum ersten Schritt kann man nach Abschätzung der Häufigkeit der Schleifendurchläufe wieder angeben, welche Routinen wesentliche Anteile an der Laufzeit des Moduls bringen. Nur für die wichtigeren Routinen lohnt sich eine Vertiefung der Analyse.

So kann man schrittweise weitergehen, bis man nur noch einige lineare Befehlsabläufe vor sich hat.

Hier kann man die Laufzeiten sehr exakt ermitteln, in besonderen Fällen sogar direkt nach der Befehlsliste aufaddieren. Wo die Befehlsausführungszeiten nicht explizit angegeben werden können (z. B. bei der /370), wird man die gesamte Berechnung zwekmäßigerweise nicht auf der Basis von Laufzeiten, sondern von Befehlen bzw. Durchsatzraten (Befehle pro Sekunde) durchführen.

Am Schluß wundert man sich, ein wie hoher Anteil der CPU-Zeit von wie wenigen Maschinenbefehlen verbraucht wird.

Höhere Sprachen

Bis jetzt war stillschweigend von ASSEMBLER-Programmierung ausgegangen worden. Da alle Erfahrungswerte für die Effizienz von Compilern nur im groben Gültigkeit besitzen, ist die Abschätzung von kleinen - in höheren Sprachen geschriebenen - Routinen nicht zu empfehlen. Hier wird man zweifellos das dritte Verfahren - die Messung - bevorzugen. Da es sich um sehr geringe Zeiten handelt, mißt man zweckmäßigerweise die Laufzeit in einer Schleife mit z. B. l000 Durchläufen, um Verfälschungen durch Timer-Makros zu verringern.

An dieser Stelle ist auch leicht abzuschätzen, ob es nicht aus Laufzeitgründen lohnen würde, die wenigen, besonders zeitkritischen Statements einem Assembler-Programm unterzubringen.

"Und heute läuft das Betriebssystem!"

In den bisherigen Betrachtungen wurde in keiner Weise berücksichtigt, daß Programme, in Form von Makros, in vielfältiger Weise die Dienste des Betriebssystems in Anspruch nehmen und von ihm gesteuert werden. Hinzu kommen andere Software-Komponenten, beispielsweise ein Datenfernverarbeitungssystem oder ein Datenbanksystem. Die Anteile der CPU-Belastung durch diese Systemkomponenten ist keineswegs zu vernachlässigen und besitzt offensichtlich eine steigende Tendenz mit der Größe des Systems. Bei der Analyse eines sehr großen Informationssystems wurde der Anteil des Betriebssystems mit etwa 30%, der der gesamten Systemsoftware mit bis zu 80% ermittelt.

Bei der Abschätzung kommt uns entgegen, daß diese Programme im allgemeinen bereits existieren, also - auch wenn die Schwierigkeiten bekannt sind - der Messung zugänglich sind, soweit nicht der Hersteller entsprechend zuverlässige Zahlen zu liefern in der Lage ist.

Der Schritt zur Simulation

Die Erfahrung zeigt, daß man mit den beschriebenen Methoden zu durchaus brauchbaren Einzelaussagen, z. B. über die CPU-Auslastung, kommen kann. In ähnlicher Weise wird man auch für die Peripherie zu quantitativen Ergebnissen kommen.

Echte Aussagen über die Response-Zeiten und das Verhalten des Systems erhält man jedoch erst, wenn man beides im Zusammenhang betrachtet, und zudem die unterschiedlichsten Parameter, z. B. Speicherplatz, Belastungsfälle usw., durchvariiert. Hier aber scheitert die Methode am Aufwand.

Hingegen sind die bis jetzt beschriebenen Analysearbeiten die ohnehin notwendige Voraussetzung für eine gute Simulation.

Das Überführen in ein Simulationsprogramm und das Austesten aber ist der geringere Teil der Arbeit.

*Peter Motzberger ist Geschäftsführer der Gesellschaft für Systementwicklung GmbH, München.