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.

Überforderten Plattenarm in fünf Minuten lokalisiert


13.11.1981 - 

Integrierter Ansatz für Performance-Überwachung und Tuning durch Omegamon-Dexan-Gespann:

MÜNCHEN (je) - Eine neue Methode zur Performance Analyse und für das System-Tunlng bietet die Münchner Candle GmbH mlt Ihrem Produkt "Omegamon/Dexan" an. Die Münchner - sie verweisen auf einen konkreten Anwendungsfall in Kalifornien, wo Omegamon/Dexan TSO-Engpässe sichtbar gemacht hat - wollen damit elnen Beitrag zur, Entlastung der Rechenzentren leisten.

Die Rechenzentren nämlich, davon ist Candle überzeugt, gehen schweren Zeiten entgegen: Personal- und Softwarekrise führen zu vielschichtigen Problemen, deren Lösung nur durch die Anwendung immer komplexerer Methoden zu erreichen sei. Der Fall, von dem hier die Rede sein soll, ist in einem Großrechenzentrum in Los Angeles vorgekommen.

Dort stiegen die TSO-Antwortzeiten, die im Normalfall bei zwei Sekunden lagen, unvermittelt auf über zehn Sekunden an. Daraufhin wurde von der Systemprogrammierung sofort Omegamon/Dexan eingesetzt, um die Ursachen hierfür festzustellen.

Degradationsanalyse

Omegamon ist ein interaktiver Realtime-Monitor für das MVS-Betriebssystem. Dexan ist die Realisierung von "Degradation Analysis", einem neuen Verfahren, das abweichend von der klassischen Methode, Betriebsmittelauslastungen zu messen, stattdessen deren Auswirkungen auf die Workload analysiert. Ziel dieses Verfahrens ist die Lokalisierung und Quantifizierung von Workload-bezogenen Engpässen. Bild 1 und 2 zeigen die Anwendung dieses Verfahrens auf eine typische Transaktion.

Sobald Dexan ein besonderes Problem anzeigt, erläutert Candle, wird eine zusätzliche Überwachung mit Omegamon/MVS-Kommandos nötig sein, um das Problem zu lösen. Omegamon und Dexan seien dazu bestimmt, gemeinsam eingesetzt zu werden und böten einen integrierten Ansatz für die Performance-Überwachung und für das Tuning. Mit Hilfe von Dexan könnten Probleme leichter und schneller eingegrenzt werden. Danach werde Omegamon dazu benutzt, das Problem zu analysieren und bei der Lösung zu helfen. Im hier geschilderten Fall stellte sich heraus, daß der Grund für die schlechten TSO-Antwortzeiten beim Paging lag. Auf Bild 3 ist die Dexan-Anzeige für die Performance-Gruppe 2 (TSO) zu sehen. Hier - unterstreicht Candle - wurde das Problem durch die Benutzung von Dexan sofort erkannt. Paging war für über 70 Prozent (also rund sieben Sekunden) der TSO-Antwortzeit verantwortlich. (Als das System gut lief, zeigte Dexan an, daß Paging weniger als 20 Prozent der TSO-Antwortzeit ausmachte.)

Da man nun wußte, daß Paging ein Problem darstellte, wurde das Omegamon-Kommando MPAG (multiplot of paging) eingegeben, um zu bestimmen, was im einzelnen Paging verursacht. Wie auf Bild 4 zu sehen ist, verursachte kein Job eine hohe Paging-Rate. Insgesamt dürften 62,3 Pages pro Sekunde kein Problem für eine 3033 UP sein. Während das Batch-Paging bei 23,5 Pages pro Sekunde lag, war TSO bei lediglich 8,0 Pages pro Sekunde. Da die Paging-Rate also innerhalb tragbarer Grenzen war, sah man sich die einzelnen Paging-Platten an der Paging-Service-Time lag. Wie man auf Bild 5 sieht, war dies der Fall. Die lokale Page Volume MVS304 hatte eine extrem hohe Service-Time von 33 Millisekunden. Da sich nur die Paging-Platte MVS304 nachteilig auswirkte, wurde beschlossen, diese Platte zu untersuchen.

Die Candle-Leute benutzten das Kommando SDSK (Statistics on disk), um zu sehen, inwieweit diese Einheit ausgelastet war. Wie bei Bild 6 zu sehen ist war sie zu 76 Prozent ausgelastet. Die SDSK-Anzeige liefert einen Durchschnitt über das laufende (Langzeit-)RMF-Intervall, das nach Erfahrung von Candle dazu neigt alle kurzfristigen Probleme unterdurchschnittlich zu bewerten. Canden Fazit: Die wirklichen kurzzeitigen Auslastungen lagen wahrscheinlich weit über 76 Prozent; MVS304 war stark, die anderen Einheiten auf Kanal 1 allerdings auch ziemlich ausgelastet.

Eine Warteschlange auf MVS304 bestand bei 47 (= 42 + 5) Prozent der entnommenen Proben. Angesichts dieser Tatsachen hätte ein Blick auf die Kanäle Näheres zeigen können, theoretisiert Candle, aber: Bild 7 zeigt keine ernsten Kanalengpässe. Kanal 1 war nur zu 17 Prozent und Kanal 7, die Ausweichmöglichkeit dazu, nur zu drei Prozent ausgelastet. Es wurde beschlossen, sich die Platte MVS304 noch näher anzusehen, um den Grund für die lange Service-Time herauszufinden.

Um MVS304 detailliert zu analysieren, gab man das Kommando DPLT (Device Plot) ein. Dieses Kommando führt Abfragen im System durch (bei diesem Beispiel in Intervallen von drei Millisekunden) und zeigt Informationen über die geprüfte Einheit. Auf Bild 8 wird gezeigt, welche Anzeige dieses Kommando ergab. Jede senkrechte Spalte stellt die Ergebnisse einer Abfrage dar. Die Ausführung dieses Kommandos machte sofort den Grund für die extrem lange Page-Service-Time deutlich:

Der Job FCSREST konkurrierte mit dem Master-Scheduler um die Einheit MVS304. Der Master-Scheduler führte Paging-I/Os aus, und der Job FCSREST sicherte eine Datei auf MVS304. Der Plattenarm wurde wechselweise von der Paging-Datei auf die Restore-Datei und zurück bewegt (zwischen Zylinder 442 und 329). Zusätzlich übertrug dieser Restore-Job lange Datensätze: Das I/O mit der Nr. 86 dauerte 13 Intervalle an. Mit jeder Spalte, die rund drei Millisekunden darstellt, ergibt dies eine I/O-Zeit von 39 Millisekunden.

Nach Entdeckung der Ursache des Problems, stellte man den Job FCSREST in eine "Swap-out"-Performance-Gruppe. Nachdem dies geschehen war besserte sich die Leistung des Paging-Subsystems (die Page-in-Zeiten gingen erheblich zurück), und die TSO-Antwortzeiten wurden wieder normal. Dieser Fall zeigte, resümiert Candle, wie Dexan und Omegamon miteinander eingesetzt werden können, um ein Problem zu erkennen und zu beseitigen. Dexan zeigte, welches Betriebsmittel das Problem verursachte und wieviel Degradation auftritt. Omegamon zeigte dann, warum dieses Betriebsmittel ein Problem war.

Informationen: Candle GmbH, Pfisterstr. 3, 8000 München, Tel.: 089/22 51 25.