SUCCESS STORY 1

 

DV-Dialog 11-2005: Beschleunigung von
„zu langsamen“ Anwendungen
Untraditionelle Methode bringt Erfolg.
 

Neue Wege beim Tuning von iSeries-Systemen beschreitet die Firma iPerformance mit ihrem Tool GiAPA, die auch bei Kunden in Deutschland überzeugende Resultate zeitigen.

In Regie von COMMON Deutschland, der Vereinigung für eServer-Benutzer der mittelständischen Industrie, fand Mitte Oktober ein Workshop zum Thema Performance-Optimierung von Anwendungen in Göttingen statt. Denn wenn die Antwortzeiten zu groß werden oder die Stapeljobs unerträglich lange dauern, dann heißt es bei den meisten Firmen normalerweise zusätzliche Hardware kaufen – es ist zu teuer, wenn vielleicht eine größere Anzahl Mitarbeiter immer an den Bildschirmen warten muss.

Denn obwohl Hardware im Verhältnis zu der Leistung immer billiger geworden ist, können die Kosten für zusätzliche CPUs, Hauptspeicher und/oder Platten erheblich sein - und ab und zu auch fast unnötig hoch erscheinen. Wie schon in DV-Dialog 3/05 erwähnt, hat die dänische Firma iPerformance ApS vor diesem Hintergrund schon seit Jahren Performance-Verbesserungen auf ein „No cure – no pay“-Basis angeboten, und später auch die dabei gewonnenen Erfahrungen in ein Software Produkt GiAPA (Global iSeries Application Performance Analyzer) eingebaut und auf dem Markt gebracht.
Wie das Tool wirkt, zeigt das Beispiel der Spedition Kühne + Nagel, die mit dem Einsatz von mehreren Model 890 zu den größten iSeries Anwendern Deutschlands gehört. Dort hatte die IT-Leitung bemerkt, dass die prozentuale Steigerung der EDV Kosten größer als die Steigerung der Anzahl behandelter Transaktionen geworden war. Daher wurde eine Arbeitsgruppe mit der Aufgabe gegründet, dieses Verhältnis zu ändern.

Diese Arbeitsgruppe betraute die dänische iPerformance damit, sie bei der Optimierung eines Stapeljobs zu unterstützen. Als das Ergebnis - eine Laufzeitverbesserung von 80 % - wesentlich besser als erwartet war, wurde entschieden, alle Jobs auf der Produktionsrechner mit den Analysemethoden von iPerformance zu untersuchen. 
Diese Methoden wurden auf dem COMMON Workshop in Göttingen von Kaare Plesner, dem Geschäftsführer von iPerformance APS, beschrieben. Die Vorgangsweise war für die Teilnehmer wahrscheinlich überraschend einfach: Die Daten von allgemein vorhandenen Anzeigebefehlen des Betriebssystems werden in Dateien geschrieben, dort sortiert und mit Abfragen oder einfachen Programmen analysiert – und plötzlich ist es in den meisten Fälle relativ einleuchtend, wodurch (und an welcher Stelle) eventuelle Performance-Schwächen verursacht werden – bis hin zur Zeilenummer im Quellcode.

Die manuelle Analyse von tausende von Jobs und Programme wäre allerdings sehr umfangreich. Bei Kühne und Nagel hat man sich deswegen dafür entschieden, eine Lizenz des Softwareprodukts GiAPA zu kaufen. Das verwendet dieselben einfachen Analysemethoden, ermöglicht aber automatische und gleichzeitige Performance-Datenerfassung für alle aktiven Jobs.
Welche Ergebnisse damit bereits erzielt werden konnten, schilderte der andere Referent bei dem COMMON Workshop: Michael Albrecht, Systembetreuer im Head Office IT bei Kühne & Nagel und verantwortlich für Performance-Untersuchungen der internationalen Standard­anwendungen. Er wusste von vielen Laufzeitverbesserungen zu berichten, die mit diesen einfachen Methoden ermöglicht wurden: Die bis jetzt erzielten Ergebnisse bei einer Model 890 im Hamburg entsprachen ungefähr 4 CPUs, die jede einen Preis in Größeordnung 250.000 Euro hatte.
Ein anderer erheblicher Vorteil bei der Performance-Datenerfassung mit GiAPA sei die dabei sehr niedrige Ressourcenverwendung von weniger als 1 Promille CPU-Zeit.
 

 

 

SUCCESS STORY 2

Batch Job für Verkaufs-Statistik um 86 % schneller

Cordes und Graefe KG in Bremen arbeitete mit einem Batch Job, der auf Basis von mehr als 30 Millionen Datensätzen mit Bestellvorgängen verschiedene Arten von Verkaufs-Statistiken erzeugte. Zur Generierung dieser Statistiken mussten weitere Informationen aus anderen Datenbanken wie Kundenstamm, Rabattstaffeln, usw. geholt werden. Insgesamt wurde dazu für jeden einzelnen Datensatz auf fünf weitere Datenbanken geschlüsselt zugegriffen. Der Job lief mit verhältnismäßig niedriger CPU-Auslastung für etwa 5 Stunden auf einem iSeries Server mit ausreichend CPU-Kapazität, Hauptspeicher und Plattenplatz.

Weil der Job sehr häufig lief, musste er performanter werden. Der erste Schritt war die genaue Feststellung, welche Teile des Jobs dabei die meiste Laufzeit beanspruchten. Eine geringe CPU-Auslastung – bei ausreichender Kapazität – deutete darauf hin, dass der Prozessor die meiste Zeit auf etwas wartet.

Der Einsatz von GiAPA (Global iSeries Application Performance Analyzer) von iPerformance zur Analyse des Jobs deckte den Grund für die geringe CPU-Auslastung leicht auf: Der Job wartete die meiste Zeit auf die Beendigung von physischen Platten-I/Os aufgrund von Millionen von synchronen Lesezugriffen auf die Datenbank. GiAPA zeigte auch auf, dass die CPU Zeit durch QDBGETKY (IBM-Befehl „Lese einen Datensatz über einen Schlüssel“) verbraucht wurde. Dabei zeigte GiAPA genau die beteiligten Programme und Quellcodezeilen der verursachenden Befehle an, die diese Lese­zugriffe anstießen. Außerdem wurden die betreffenden Dateinamen angezeigt. Auch wenn diese Dateien bereits bekannt waren, konnten sie mit GiAPA als Verursacher eingegrenzt werden.

Der Direktzugriff auf unterschiedliche große Datenbankdateien erlaubte es dem „Expert-Cache“ des Betriebssystems nicht, die benötigten Datensätze im Voraus verfügbar zu machen. Und die Dateien waren zu groß, um sie im Hauptspeicher vorzuhalten.

Es wurden aber nur sehr wenige Felder der direkt gelesenen Dateien benötigt. iPerformance schlug daher vor, jede dieser Dateien zu Beginn eines Jobs zu lesen und dabei die Methode des sequentiellen geblockten Zugriffs zu verwenden. Die Schlüsselfelder und die wenigen Bytes benötigter Daten sollten in Benutzer-Indizes geladen werden. Alle direkten Datenbank-Zugriffe konnten anschließend durch Befehle zur Indexsuche ersetzt werden. Dadurch wurden die Indizes nie größer, als es das Speichermanagement erlaubte, ohne sie aus dem Hauptspeicher zu entfernen.

Die Strategie ging erfolgreich auf. Die neue Version des Programms benötigt nur 40 Minuten Laufzeit.Auch die insgesamt genutzte CPU-Zeit konnte verringert werden, auch wenn die CPU-Auslastung währenddessen sehr hoch ist – der Job muss jetzt nicht mehr auf die Daten warten, die von der Platte angefordert werden. Aber mit der geringen Priorität des Batch Jobs wird dieser nicht wieder irgendwelche interaktiven Jobs stören.

Die Strategie ging erfolgreich auf. Die neue Version des Programms benötigt nur 40 Minuten Laufzeit. Auch die insgesamt genutzte CPU-Zeit konnte verringert werden, auch wenn die CPU-Auslastung währenddessen sehr hoch ist – der Job muss jetzt nicht mehr auf die Daten warten, die von der Platte angefordert werden. Aber mit der geringen Priorität des Batch Jobs wird dieser nicht wieder irgendwelche interaktiven Jobs stören.

 

 

SUCCESS STORY 3

 

GiAPA bei Tele Columbus

Wie Tele Columbus die iSeries-Kapazitäten optimiert

Analyse von Lastspitzen

Die Tele Columbus Daten und Service GmbH, Hannover, hatte ein kniffliges Kapazitäts­planungs­problem zu lösen, bevor die IT-Tochter der Kabel-Servicegesellschaft für eine große Anzahl zusätzlicher User eine ihrer wichtigsten interaktiven iSeries-Applikationen bereitstellen konnte. Die Frage war: Wieviel zusätzliche Rechenleistung, gemessen in CPW, war nötig?

Die fragliche Applikation wurde bereits an vielen Arbeitsplätzen genutzt und konte durch ihre Jobnamen durch die Systemadministratoren auch eindeutig identifiziert werden. Doch um den zusätzlichen Ressourcenbedarf zu ermitteln war es nicht ausreichend, den gesamten CPU- und I/O-Bedarf dieser Jobs zu analysieren, da die Nutzung dieser Applikation je nach Tageszeit stark variierte und einige signifikante Spitzen aufwies. Die Kapazitätsplanung auf den Gesamtbedarf der aktuellen User aufzubauen wäre ähnlich zum Scheitern verurteilt gewesen wie die Dimensionierung einer Autobahn auf Basis der täglichen Fahrzeugzahlen, ohne die Berücksichtigung der Verkehrsspitzen am Morgen und Abend.

Andererseits hätte eine Auslegung der Kapazitäten auf die bekannten Lastspitzen hin ein unnötig großes Investment bedeutet. Also erschien eine detailliertere Analyse des Systemverhaltens sinnvoll. Die notwendigen Fakten dazu wurden von GiAPA geliefert, dem Global iSeries Application Performance Analyzer des dänischen Softwarehauses iPerformance (www.giapa.com). Dieses Software-Tool sammelt alle 15 Sekunden die Performance-Daten aller Jobs und Tasks auf der Maschine. Während der anschließenden automatischen Analyse werden alle im Normalbereich liegenden
Daten aus dem Bericht gelöscht.

Es gibt aber auch die Option, alle Daten aufzubewahren. In diesem Fall erlaubt GiAPA den Bericht nach User-definierten Kriterien auszuwerten. Dazu zählt auch die Möglichkeit, automatisch alle Daten zu bestimmten Jobnamen zu sammeln und auszuwerten. Bei Tele Columbus wurden aus den so gesammelten Performance-
Daten zwei Berichte generiert:


•   Ein Histogramm zeigte an, in wie vielen 15-Sekunden-Intervallen jeder prozentuale CPU-Verbrauch

    erreicht worden war.


•   Je 15-Sekunden-Intervall wurde der CPU- und I/O-Bedarf aufgelistet, und zwar für die betrachteten

    Job der Anwendung sowie für das Gesamtsystem.

Der erste Bericht dokumentierte, dass Lastspitzen in der Nähe von 100 Prozent CPU-Auslastung zwar vorkamen, aber nur sehr selten. Ein Upgrade auf Basis dieser Spitzen wäre somit ein Overkill gewesen und hätte eine Verdoppelung der CPU-Kapazitäten erfordert. Um den CPU-Bedarf für 99,5 Prozent aller Fälle zu sichern, erwies sich ein deutlich kleinerer Upgrade als ausreichend.

Der zweite Bericht, der auch die Plattenzugriffe dokumentierte, machte deutlich, dass die für die zusätzlichen User nötigen I/O-Kapazitäten bereits vorhanden waren – auch unter Berücksichtigung aller übrigen Anwendungen auf dem Server. Außerdem bestätigte er die Ergebnisse der Histogramm-Analyse: Die übrigen Anwendungen auf dem Server, die parallel zu den betrachteten Jobs liefen, machten keinen zusätzlichen CPU-Upgrade erforderlich.

So hat der Performance-Monitor GiAPA, obwohl nie als Kapazitätsplanungs-Werkzeug gedacht, dank seiner Fähigkeit, Job-bezogene Performance-Daten in bis zu 15 Sekunden kurzen Intervallen zu sammeln und zu analysieren, dem Management bei Tele Columbus wertvolle Informationen geliefert, um seine Entscheidung über ein Hardware-Upgrade auf eine abgesicherte Faktenbasis zu stellen.


 

SUCCESS STORY 4

 

Warum verzögern sich Jobs trotzt genügend grosser System i5?

Kühne + Nagel (AG & Co.) KG in Hamburg bekam erhebliche Performance Probleme, als sich Printjobs in den Jobqueues ihres iSeries Server zu anzusammeln begannen. Frachtbriefe, Rechnungen, usw., die normalerweise innerhalb von Sekunden gedruckt wurden, hatten plötzlich Verzögerungen von mehreren Stunden.

Dies stellte natürlich eine ernsthafte Bedrohung für den ordentlichen Geschäftsbetrieb dar. Die Printjobs waren jahrelang fehlerfrei gelaufen und es waren keine Änderungen vorgenommen worden.

Der Server war in keiner Weise überlastet – eine durchschnittliche CPU-Auslastung von etwa 65% bedeutete, dass 4 bis 5 der insgesamt 16 CPUs die meiste Zeit im Leerlauf waren. Auch die Platten-I/O-Raten befanden sich innerhalb der erlaubten Werte. Viele Batch-Jobs für die Druckausgabe liefen parallel, benötigten aber so gut wie keine Server-Ressourcen – vielmehr schienen sie über lange Zeiträume nicht mehr weiter zu laufen.

Die Gründe für Performance Probleme sind leicht einzusehen, wenn Jobs eine Menge Ressourcen benötigen. Aber es ist wesentlich schwieriger den Grund zu finden, wenn so gut wie keine Ressourcen verbraucht werden. Ein Record- oder Objekt-Lock war eine nahe liegende Vermutung für die Probleme, schien aber hier nicht die Ursache zu sein. Ferner war die Anwendung speziell für den Parallelbetrieb vieler Jobs entworfen worden – und natürlich keinerlei Locks zu erzeugen. Und mit der annähernd gleich bleibenden Anzahl an Transaktionen wären die Locks schon viel früher aufgetreten.

Erfreulicherweise hatte die Firma noch ein Ass im Ärmel: Das Software Paket GiAPA von iPerformance. GiAPA (Global iSeries Application Performance Analyzer) enthält Optionen zur Analyse von verzögerten Jobs, die nicht weiter laufen. Die GiAPA Trace Job Analyse zeigte, dass die Verzögerungen, die teilweise über 30 Sekunden betrugen, immer dann auftraten, wenn eine Datenbankdatei oder ein „Member“ in QTEMP angelegt oder gelöscht wurde, z.B. innerhalb von IBM Programmen wie QDBCRTME (Data Base Create Member).

Mit dieser Erkenntnis in der Hand konnte der Ball der IBM zugespielt werden. Die fanden heraus, dass „Seize Waits“ (Seize = Betriebssystem-interner Lock) während des Updates der Liste eigener Objekte des User-Profils QDBSHR das Problem verursachten.

IBM entschied anschließend ein PTF herauszugeben, um das Problem für die aktuelle Version zu  beheben und wird die Änderung selbstverständlich in die neuen Betriebssystem-Versionen einbauen.
Zwischenzeitlich konnte das Problem durch das Leeren und die Wiederverwendung der Dateien in QTEMP umgangen werden, anstatt sie zu erzeugen und zu löschen. – Die Ausdrucke wurden wieder innerhalb von Sekunden ausgegeben.

 

 

SUCCESS STORY 5

Wird später zugefügt