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.

21.07.1989 - 

Die Softwaremöglichkeiten bleiben oft unbeachtet, aber:

Mehr MIPS bedeuten selten die wirtschaftlichste Lösung

Eine bessere Performance kann selbstverständlich durch eine Aufstockung der Hardware erreicht werden. Diese Methode ist relativ zuverlässig, aber auch recht teuer. Das Problem von der Softwareseite anzugehen, kommt den Anwendern oft billiger. Herko Steuer* nennt die Details.

Die Entwicklung der Hardware vollzieht sich so rasant, daß es möglich ist, fast jede Schwäche der Software in bezug auf Performance durch erhöhte CPU-Leistung oder leistungsfähigere Peripherie auszugleichen. Die Preise der Hardwareanbieter pro MIPS sinken. Es sind auch durchaus Tendenzen erkennbar, daß die Anwender die (verlockenden) Angebote der Hardwareanbieter annehmen und somit die Probleme im Ursprung ungelöst bleiben.

Dabei ist es durchaus möglich, 10 bis 30 Prozent der Dialoglast und 20 bis 30 Prozent der Batchlast durch kurzfristige Tuning-Maßnahmen, insbesondere System-Tuning, einzusparen - zumindest im General-Purpose-Bereich mit den

- Betriebssystemen VSE/SP, MVS/ 370, MVS/XA, VM/SP, VM/XA und BS2000, den

- Datenbanksystemen IMS/DB, DB2, IDMS/R, Adabas, UDS und Sesam, den

- Datenkommunikationssystemen CICS, IMS/DC, UTM und ATM, den

- Datenstrukturen VSAM, Leasy, ISAM, SAM und UPAM, den

- Programmiersprachen Assembler, Cobol, RPG, Natural, SQL und Ideal sowie den

- Anwendungssoftwarepaketen, zum Beispiel von SAP, Orga-Ratio, Steeb, ADV/Orga und Lammert.

Dabei wird Tuning als eine Optimierung der Systemperformance durch Änderung von Systemparametern verstanden. Aus der Praxis hat sich eine Tuning-Hierarchie ergeben, die sich wie folgt darstellt:

1. Hardware

2. Betriebssystem

3. Datenfernverarbeitung

4. Datenkommunikationssystem/Datenbanksystem

5. Anwendungen.

Die Tuning-Ziele sind dabei immer auf das jeweilige Anwender- und Anwendungsprofil bezogen; sie sind also temporär. Beispiele dafür sind die Verringerung der Antwortzeiten im Dialog oder die Verkürzung der Batchlaufzeiten.

Tuning insgesamt ist jedoch ein permanenter Prozeß, da sich die Anforderungen an das System sehr schnell ändern und unterschiedlich stark bedeutsam sind. Generelles Ziel des Tuning ist es aber immer, den Einsatz von Ressourcen zu minimieren beziehungsweise Ressourcen gegeneinander auszutauschen.

Parameter dürfen nicht einzeln verändert werden

Zu beachten ist auf jeden Fall, daß Tuning-Maßnahmen in ihrer Gesamtheit gesehen werden müssen und demzufolge Parameter nicht willkürlich und unabhängig voneinander austauschbar sind. Folgende Vorgehensweise sollte eingehalten werden:

Im ersten Schritt wird das Untersuchungsziel unter Beachtung des Tuning-Ziels analysiert. Zu betrachten sind dabei die Systemgenerierung, die Netzsoftware sowie die Dialogprogramme, Datenbankstrukturen und Batchprogramme.

Der zweite Schritt besteht in der Festlegung durchzuführender Tuning-Maßnahmen. Die Anforderungen der Fachabteilungen müssen integriert werden. Außerdem ist ein Realisierungsplan zu erstellen. Im dritten Schritt werden dann die Tuning-Maßnahmen realisiert und im vierten in die Praxis eingeführt.

Wenn eine umfassende Tuning-Maßnahme durchgeführt werden soll, müssen alle Hierarchien des Tuning beachtet werden. Dafür ist es notwendig, geeignete Tools zur Messung einzusetzen.

In der Regel werden nach Einsatz der Meß-Tools alle Kräfte in die erste Hierarchiestufe (Hardware) gesteckt. Ohne überhaupt die weiteren Hierarchiestufen zu bearbeiten, wird das Equipment geändert. Tatsächlich kann die Entscheidung für eine Änderung aber erst dann richtig getroffen werden, wenn alle Hierarchiestufen im Zusammenhang betrachtet worden sind.

Aus vielfacher Erfahrung haben wir festgestellt, daß sich oftmals durch ein System-Tuning für die zweite bis vierte Hierarchiestufe die Änderung des Equipments erübrigt. Folgendes Beispiel soll dies veranschaulichen:

Die Mehrzahl der installierten Mainframes werden im gemischten Dialog- und Batchbetrieb sowie mit Software der verschiedensten Hersteller genutzt. Für beide Betriebsarten ergeben sich die Antwortzeiten aus der Summe von reiner CPU-Zeit, Paging, Detai-I/O und nachzuladenden Programmen.

Damit die Antwortzeiten generell verbessert werden können, sind folgende Grundprinzipien einzuhalten:

-- Optimierung der Katalogverwaltung (Master- und User-Kataloge, Einsatz von Tools zum Direktzugriff innerhalb des Katalogs)

-- Minimierung der Katalogeinträge

-- Verringerung des Paging durch optimale Programmgrößen unter Beachtung des zur Verfügung stehenden Benutzeradreßraumes durch geeignete Datenstrukturen (Block- und Puffergrößen) sowie durch Verwendung von mehrfach benutzbaren hauptspeicherresidenten Modulen (vor allem bei Dienstprogrammen)

- Optimierung des DMS durch ausreichend Primary-Allocation, damit die Extents möglichst gering

gehalten werden, durch hardwareneutrale Speicherung (Siemens in PAM-Blöcken Ó 2048 Bytes generell, IBM nach Blocklänge und Blockanzahl möglich), durch Beachtung einer sinnvollen Daten- und Indexpufferung in bezug auf Datenkomprimierung, Ausnutzung der möglichen Übertragung von 32 KB pro Control-Intervall in VSAM und 16 x 2048 bei Siemens, Paging und Blockbeziehungsweise CI-Splitting sowie durch Freispeicherverwaltung

- Ausnutzung der Dienstprogrammmöglichkeiten in bezug auf Hauptspeicherzuweisung, explizitem Anlegen der Work-Dateien in ausreichender Größe und mit sinnvoller Pufferung sowie Zuweisung spezieller Softwareregister.

Da die Datei-I/O-Zeiten in der Regel mehr als 50 Prozent der Gesamtzeiten ausmachen, ist die Optimierung des Datenbanksystems von größter Bedeutung. Dateien, die ausschließlich im Batch genutzt oder im Dialog nur beschrieben werden, müssen hinsichtlich Daten- und Indexpufferung anders behandelt werden als gemischt genutzte oder reine Dialogdateien.

Die reine Arbeitsmittelsteuerung mit dem "Performance Control Subsystem" unter BS2000 oder mit dem "System Ressource Manager" unter MVS nimmt eine Optimierung nach CPU-Auslastung, Hauptspeichernutzung, I/O-Belastung und Kanalbelastung vor. Die Dateibehandlung bleibt jedoch nach wie vor Sache des Anwenders.

Nach unseren Erfahrungen dauert das Tuning für ein System etwa 40 Manntage einschließlich einer Angebotsphase mit Voruntersuchung, die vorangestellt werden muß. Der finanzielle Aufwand beträgt 60 000 bis 80 000 Mark. Die Frage ist, ob sich das System-Tuning bei solch einem Aufwand lohnt.

Hardware-Kauf kommt meist teurer als Software-Tuning

Die Antwort lautet: Ja! Speicheraufrüstung, CPU-Leistungssteigerung und externe Speicherplatzerweiterung lassen sich nämlich im angesprochenen Marktsegment nicht für 80 000 Mark realisieren. Oftmals sind mit einer leistungsfähigeren CPU auch eine Veränderung der Softwareklasse für das Betriebssystem oder der Einsatz entsprechender Tools verbunden.

Trifft dies zu, so beträgt der Mehraufwand zwischen 100 000 Mark und einer halben Million. System-Tuning lohnt sich auch unter der Maßgabe, daß ein Know-how-Transfer erfolgt und das Tuning als ständige Aufgabe nun weitestgehend selbständig durchgeführt werden kann.

Bei der Auftragsvergabe zum Tuning des bestehenden Systems sollten auf jeden Fall Ziele definiert werden, die meßbar und realistisch sind. Die Integrität von Betriebssystem, DB/DC-Software und Anwendungsprogrammen ist so komplex, daß System-Tuning eine Sache von Spezialisten ist. Tuning ist jedoch in jedem Falle die wirtschaftliche Alternative zur kurzfristigen Ressourcen-Aufstockung im Rechenzentrum.