CLEVELAND/OHIO - Zur Halbzeit der diesjährigen US Computer Caravan durch neun amerikanische Großstädte (bisherige Stationen: Atlanta, Philadelphia, Hartford, New York and Cleveland) bezeichnet Edward J. Bride, Caravan-Manager, die Ergebnisse der Arbeitsgruppen "Virtual-versus-Real-Storage-Workshop" als "praktisch identisch mit den Konsequenzen die auch John J. Hunter in einem kürzlich veröffentlichten Beitrag gezogen hat". ¹)

Anwender berichten immer wieder über folgende Probleme:

- Die Programme laufen länger als vor der Umstellung auf Virtuelle Speicherung (VS).

- Die teure Peripherie wird zweckentfremdet belastet.

- Die Zentraleinheit arbeitet immer weniger produktiv.

Dabei hatte man sich vom Umstieg auf VS Throughput - Verbesserungen davon versprochen, daß durch den Fortfall der Speicherbegrenzung mehr Programme simultan auf der Anlage gefahren werden konnten.

VS war verkauft worden mit Argumenten wie: "Die Anwendungen können jetzt komfortabler werden, weil die Programmgröße keine Rolle mehr spielt", oder: "Die Hardware ist so schnell, daß Sie gar nicht bemerken, wenn Programmteile von der Platte eingelesen werden müssen. "Waren das falsche Versprechungen? Im Prinzip nicht.

Das sind die Gründe

In vielen Fällen hatten die Anwender ihre bestehenden Programme unverändert auf das neue System übernommen. Ohne zu berücksichtigen, daß bei realer Speicherung lediglich ein Programm-Segment überlagert wird, wenn Daten eingelesen werden sollen, während die virtuelle Anlage respektive ihr Betriebssystem bei dieser Gelegenheit bis zu 19 zusätzliche Operationen durchzuführen hat. Es bedarf keiner großen Phantasie, sich den Zeitbedarf auszumalen.

Und vom Performance-Killer "Exzessives Paging" hat auch schon jedes gehört.

Kommerzielle Anwendungen sind in der Regel I/O-Intensiv. Durch die bei jedem Paging zusätzlich erforderlichen I/O-Operationen wird im günstigsten Fall die Verarbeitung gestört, im ungünstigsten kommt es zu einem Zustand, den die Amerikaner "thrashing" nennen, was man vielleicht mit Parkinson'sche Agonie übersetzen könnte: Es wird nichts mehr verarbeitet, das System ist ausschließlich mit I/Os beschäftigt.

Diese Lösungen bieten sich an

Industrie-Experten kamen (überraschend?) schnell zu der Ansicht daß das Problem nur durch zusätzliche Hardware gelöst werden könne. Optimierungs-Profis schlugen vor, den Job-Mix zu verbessern. Und die Besonnenen fragten sich, wo die Ursachen liegen könnten und sahen sich die Anwenderprogramme genauer an. So entstand ein Katalog von Maßnahmen, die den Performance-Verlust ausgleichen sollen:

- Einsatz einer schnelleren Zentraleinheit

- Aufrüstung des realen Speichers

- Verwendung von mehr und/oder schnelleren Kanälen

- Umstieg auf schnellere Platten oder Trommeln

- Optimierung des Job Mix

- Überarbeitung der Anwendungsprogramme

Teure Hardware-Erweiterungen

Nur die letzte Maßnahme packt das Übel an der Wurzel. Bei der ersten wird man das Management nur schwer davon überzeugen können, daß sich der Mehraufwand - letztlich zur Wiederherstellung des alten Zustandes - lohnt. Durch Vergrößerung des realen Speichers kann die Paging-Häufigkeit abnehmen, aber die Lösung ist teuer.

Zusätzliche Kanäle eröffnen neue Daten-Wege, schnellere Kanäle erhöhen den Durchsatz: in beiden Fällen sollte sich die Page-Übertragungsrate verbessern lassen. Untersucht werden sollte aber das Ausmaß der möglichen Performance-Steigerung, damit nicht viel Geld für marginale Verbesserungen aus dem Fenster geworfen wird. Natürlich können auch schnellere Random-Speicher das Paging beschleunigen, besonders wenn sie mit schnelleren Kanälen kombiniert werden. So beträgt zum Beispiel die mittlere Zugriffszeit zu einer Page bei IBM 2314/2319 Platten 72,5 msek. Mit Platten vom Typ IBM 3330 kann diese Zeit auf 38,3 msek. verkürzt werden. Aber alle Hardware-Verbesserungen befassen sich nur mit den Symptomen.

Isolierung des "Working Set"

Durch die Kombination von I/O-intensiven mit rechen-intensiven Programmen lassen sich in vielen Fällen beim Job Mix Verbesserungen erzielen, aber das eigentliche Problem des Paging ist nur dadurch zu lösen, daß man die einzelnen Programme daraufhin untersucht, weiche Befehle am heutigsten ausgeführt werden. Sie sollten möglichst ständig im realen Speicher sein. Nicht seiten wird man dabei die 80 - 20 Regel bestätigt finden: 20 Prozent der Befehle benötigen 80 Prozent der CPU-Zeit. Diesen "harten Kern" der Programme bezeichnet man als Working Set.

Bis zu 90 Prozent weniger Paging-Operationen

Beim IBM-VS wird ein Programm - abhängig von der OS-Version - wahllos in 2 K oder 4 K große Pages aufgeteilt. Das führt bei der gängigen Programmier-Praxis, die Programmsteuerung von den verarbeitenden Unterprogrammen zu trennen, häufig dazu, daß die Programmsteuerung oder Mainline, die praktisch nur aus Abfragen und Verzweigungen besteht, virtuell gespeichert ist und so exzessiv "gepaged" werden muß.

Nach Aussagen von IBM fassen sich 50 bis 90 Prozent der Paging-Operationen einsparen, wenn die Programme so umgeschrieben werden, daß der Working Set auf benachbarten Pages während der Programmausführung als "non pageable" im Hauptspeicher gehalten wird.

Es werden Programme umgeschrieben

Leider ist die Isolierung des Working Set alles andere als einfach, zumal er sich im Ablauf der Anwendung verändern kann. Trotzdem ist das Überdenken der Programme lohnend, notfalls müssen nacheinander mehrere Working Sets im Hauptspeicher gehalten Werden.

Beim Neu- oder Umschreiben der Programme muß darauf geachtet werden, daß

- der Aufbau modular ist,

- zusammen benutzte Module Möglichst auf derselben Page stehen,

- selten benutzte Module an das Programmende gelegt werden und

- die nach einer Verzweigung anzusteuernde Routine nahe am Verzweigungsbefehl liegt, möglichst auf derselben Page.

Der Aufwand ist groß, aber einmalig. Hardware-Erweiterungen kosten laufend Miete. Bleibt die Hoffnung, daß reale Speicher bald so billig werden , daß VS eine Ausnahme darstellt, denn änderungsfreundlicher werden die Programme durch eine VS-gerechte Strukturierung sicher nicht.

¹) Computerworld, 28. März 1975: "Rethinking Application Programs Key to VS Success" John J. Hunter, Project Editor for Auerbach Computer Technology Reports.