Auf dieser Seite befindet sich Wissenswertes zum AS/400 Workmanagement und zum Thema Performance


Work Management

1. Steuerndes Subsystem
   
   Außer bei ganz kleinen Systemen sollte immer QCTL als Steuerndes Subsystem gestartet werden. Hierdurch bieten sich viel mehr Möglichkeiten das System seinen Bedürfnissen anzupassen. Das Steuernde Subsystem wird durch den Systemwert QTCLSBSD bestimmt.
   
   
2. Startprogramm
   
   Das Startprogramm ist bei Auslieferung QSTRUP in der Bibliothek QSYS. Dieses läßt sich an eigene Bedürfnisse anpassen indem man sich mit RTVCLSRC den Sourcecode holt und diesen ändert Es empfiehlt sich nicht das original Startprogramm zu überschreiben, sondern das geänderte unter einem anderen Namen zu übersetzen. Danach muß der Systemwert QSTRUPPGM auf den neuen Programmnamen geändert werden.
   
   
3. Performance Adjuster und Expert Cache
   
   Das Verhalten des Performance Adjusters wird durch den Systemwert QPFRADJ bestimmt. Sinnvolle Einstellungen sind 0 oder 3. Bei 0 werden keine Anpassungen vorgenommen, bei 3 werden die Poolgrößen alle 20 Sekunden überprüft und angepaßt. Wenn sich im Normalbetrieb die Verteilung zwischen Interaktiver und Batcharbeit nicht sehr verändert, so kann man nach Anpassung der Poolgrößen den Systemwert QPFRADJ auf 0 setzen. Sollte sich das Verhältnis häufig ändern, so ist der Wert 3 zu empfehlen. Der Expert Cache wird dadurch aktiviert, das man die Seitenwechselangaben der Pools von *FIXED auf *CALC ändert. Da Expert Cache und Performance Adjuster sich gegenseitig behindern können sollte nur eins von beiden aktiv sein. Wenn mit Java gearbeitet wird, so muß der Activity Level in dem Pool in dem die Java Programme ausgefürt werden ( meistens der BASE-Pool ) sehr hoch sein ( ca 1000 ), da Java sehr viele Threads erzeugt. Diese Einstellung wird meistens durch den Performance Adjuster wieder zunichte gemacht. Deshalb sollten die Poolgrößen und Activity-Level in diesem Fall besser von Hand eingestellt und QPFRQADJ auf 0 gesetzt werden.
   
   
4. Batch Jobs sollten nicht im BASEPOOL laufen
   
   Damit Batch Jobs andere Dinge nicht behindern, sollte man sie nicht im BASEPOOL laufen lassen. Hierfür müssen ein oder mehrere SHARED Pools angelegt werden. Der entsprechende Pool muß dann in die Subsystembeschreibung eingetragen werden. Es empfiehlt sich unter umständen auch für das Subsystem QCMN einen anderen Pool anzulegen.
   
   
5. Mehrere Interaktive Subsysteme
   
   Manchmal ist es sinnvoll oder nötig mehrere interaktive Subsysteme anzulegen. Bei mehr als 300 aktiven Bildschirmen sollte auf jeden Fall ein zweites interaktives Subsystem angelegt werden, da der Subsystemmonitor z.B. recoveryaktionen nur Sequentiell durchführt. Manchmal ist aber auch eine Trennung nach Arbeitsgebieten sinnvoll. Ein neues interaktives Subsystem kann man dadurch erstellen, das man die Beschreibung von Qinter auf einen anderen Namen kopiert. Um zu vermeiden, das alle interaktiven Subsysteme versuchen sich alle Einheiten zu greifen und einfluß darauf zu haben welche Bildschirme wo landen, müssen diese in den Subsystemen eingetragen werden. Dieses kann nach Workstationtyp oder Workstationname geschehen. Normalerweise hat man über den Namen mehr Kontrolle. Um einen Bildschirm mit einem bestimmten Namen in einem bestimmten Subsystem laufen zu lassen muß er dort hinzugefügt werden. Dieses geschieht mit dem befehl ADDWSE und dem Parameter at *SIGNON. Bei allen anderen interaktiven Subsystemen sollte ebenfalls ein Eintrag für diesen Bildschirm hinterlegt werden aber mit at *ENTER.
   
   
6. Das Benutzerprofil QSECOFR
   
   Wie für alle von IBM gelieferten Benutzerprofile sollte auch für den Benutzer QSECOFR das Standardkennwort geändert werden. Dieses ist auch bei der Installation gefordert. Da QSECOFR aber ein Benutzer mit allen Berechtigungen ist sollte man vielleicht noch einen Schritt weiter gehen. Leider benötigt manche Software zur Installation die Anmeldung mit dem Benutzer QSECOFR. Für QSECOFR gibt es jedoch eine Besonderheit. Wenn man das Benutzerprofil auf DISABLED setzt, kann er sich trotzdem noch an der Systemkonsole anmelden. Wenn der Rechner und die Konsole also in einem gesichertem Raum stehen bietet diese möglichkeit einen guten Schutz.
   
   
7. Der Dynamische Prioritätsscheduler
   
   Der Dynamische Prioritätsscheduler sorgt dafür, das Jobs die einen hohen CPU verbrauch haben und lange einen Activitylevel behalten eine schlechtere Priorität erhalten. Dadurch erhalten auch noch andere Jobs auf derselben Prioritätsebene noch CPU-zeit. Der Dynamische Prioritätsscheduler wird durch die Systemwerte QDYNPTYSCD und QDYNPTYADJ gesteuert. Der Effekt ist, das auch wenn ein Interaktiver Job sonst die ganze Maschine blockieren würde alle anderen noch zügig bedient werde.
   
   
8. ASP Balancing
   
   In den neueren Versionen bietet OS/400 die möglichkeit die Verwendung der Platten zu beeinflussen. Hierfür gibt es den Befehl STRASPBAL. Die erste Version dient dazu die Daten nach einer Plattenaufrüstung gleichmäßig zu verteilen, die zweite Variante in Kombination mit TRCASPBAL ermöglicht die Daten nach Zugriffshäufigkeit neu zu verteilen um eine gleichmäßigere Auslastung der Plattenarme zu erreichen.

1. Guidelines
   
   Resource Utillisation Guidelines
   
   

Resource	Gut	Akzeptabel	Schlecht
CPU Pty < 20 ( 1 Prozessor )	< 70%	70 - 80%	> 80%
CPU Pty < 20 ( 2 Prozessoren )	< 76%	76 - 83%	> 83%
CPU Pty < 20 ( 3 Prozessoren )	< 79%	79 - 85%	> 85%
CPU Pty < 20 ( 4 Prozessoren )	< 81%	81 - 86%	> 86%
Disk Arm	< 40%	40 - 50 %	> 50%
Disk IOP	< 70%	70 - 80%	> 80%
Local WS IOP	< 25%	25 - 40%	> 40%
Multifunction IOP	< 35%	35 - 50%	> 50 %
Communications IOP	< 35%	35 - 50 %	> 50 %
Remote WS Conntroller	< 40 %	40 - 50 %	> 50 %
LAN IOP	< 35 %	35 - 50 %	> 50 %
Remote Line	< 30 %	30 - 40 %	> 40 %

Physical Disk I/O per Transaction Guidelines

Art der Synchronen I/O´s	Anzahl I/O´s
DB - reads	20 oder weniger
DB - writes	13 oder weniger
Total I/O	65 oder weniger

Machine Pool Non-Database Faults

Gut	Akzeptabel	Schlecht
< 10	10 - 15	> 15

Sonstiges :

Die Anzahl CPU-Sekunden pro Transaktion sollte kleiner als 0,25 sein.
Die Platten sollten zu maximal 80 % belegt sein.
Wenn die Guidelines überschritten werden sollte man auf jeden Fall versuchen die Ursache aufzuspüren und die Ursache zu beseitigen.

• Was kann die AS/400 leisten ?

Einen Überblick, was das Sytem leisten kann kann man im Buch Performance Capabilities finden. Dieses läßt sich jedoch nicht immer einfach auf eigene Anwendungen übertragen. Trotzdem lohnt ein blick in dieses Buch

• Synchrone und Asynchrone I/O´s

Die AS/400 liest immer Seiten von 4Kb in den Hauptspeicher. Wenn sich in so einer Seite mehrere Sätze einer Datei befinden, so findet das lesen dieser Sätze asynchron statt. Bei geschlüsselten Zugriffen muß in der Regel bei jedem Lesen mindestens eine neue Seite pro Satz in den Hauptspeicher geholt werden. Das Lesen findet hier synchron statt. Ob Synchron oder Asynchron geschrieben wird, hängt davon ab wie die Datei geöffnet bzw. erstellt wurde. Synchrone I/O´s bedeuten immer einen Direkten Plattenzugriff (evtl. wird dieser jedoch im Platten-IOP gecached ) Asynchrone I/O´s sind Hauptspeicherzugriffe und sind für die Performance nicht relevant.

• Was kann wie gemessen werden ?

Klassischer Interaktiver Workload kann sehr gut mit dem Performance Monitor gemessen werden. Bei anderen Aufgaben versagt dieses Tool jedoch. Einen guten Überblick wo CPU verbraucht wird gibt das Job Accounting, hier kann man bereits erste Anregungen bekommen wo man eingreifen sollte. Client/Server Workload läßt sich eigentlich nur noch mit dem Performance Explorer messen.

• Die Zusammensetzung der Antwortzeit

Die Antwortzeit setzt sich aus drei Bestandteilen zusammen. Die Input-Line-Time, Host-Response-Time und Output-Line-Time. Die Input und Output-Line-Times lassen sich eigentlich nur durch eine schnellere Leitung oder eventuellen austausch eines überlasteten IOP´s beschleunigen. Die Host-Response-Time gliedert sich noch in weitere Bestandteile auf.

Ineligible-Time : Die Zeit bis ein Job alle benötigten Ressourcen und eine Activity Level hat.

CPU-Time : Die Zeit für die das Programm wirklich die CPU braucht. CPU-Zugriffe sind durch die Laufpriorität gesteuert.

Waiting for CPU : Die zeit die der Job auf die Zuteilung der CPU wartet.

Disk-I/O : Die Zeit die für Plattenoperationen benötigt wird.

Waiting for Disk I/O : Die Zeit die der Job wartet bis ein Plattenzugriff beendet ist. Plattenzugriffe werden nicht durch die Ausführungspriorität gesteuert.

Warten im Activity Level: Z.B. warten auf das öffnen und schließen von Dateien.

Exceptional Wait Time : Z.B. Satzsperren oder das pflegen von Zugriffspfaden.

• Überprüfen der Guidelines mit OS/400 Befehlen

WRKSYSSTS : Daten für ca. 5 Minuten sammeln und die Page Faults mit den Guidelines vergleichen. Die Belegung der Platten ist hier ebenfalls zu sehen. Weiterhin auf Wait to Ineligible oder Aktiv to ineligible Übergänge achten. Der Wert sollte kleiner als 0,2 sein.

WRKDSKSTS : Auch hier die Daten für ca 5 Minuten sammeln. Hier ist die Anzahl und die Auslastung der Plattenarme zu sehen. Die Auslastung der Plattenarme sollte gleichmäßig und innerhalb der Guideline sein.

WRKACTJOB : Auch hier die Daten für ca 5 Minuten sammeln. Die Ausgabe läßt sich mit F16 sortieren. Wenn man nach Jobtyp sortiert kann man die Interaktive CPU-last aufaddieren.

• Der Performance Monitor

Für weitere Analysen braucht man den Performance Monitor. Dieser gliedert sich in 2 Teile. Die Befehle um Daten zu sammeln und die Befehle zum Auswerten. Das sammeln der Daten ist immer möglich, zum auswerten braucht man das Lizenzprogramm Performance Tools. Bei mehreren Maschinen ist es möglich die Daten der einen Maschine auch auf einer anderen auszuwerten. Die Sammlung und Anzeige der Werte ist ab V4R3 auch mit dem Operations Navigator möglich, jedoch erhält man hier nicht so Präzise Daten wie bei den Performance Tools. Eine weitere Möglichkeit ist die Dateien der Performance Datensammlung mit Hilfe von Querys oder eigenen Programmen auszuwerten. Eine Beschreibung der Dateien und einige Hinweise finden sich im Buch WORK-MANAGEMENT.

• Starten des Performance Monitors

Zum starten des Performancemonitors dient der Befehl STRPFRMON. Hierbei sollte das Time Interval auf 5 Minuten gesetzt werden. Für komplexere Auswertungen braucht man Trace Daten. Hierzu muß der Parameter Trace type auf *ALL gesetzt werden. Wird Trace type auf *ALL gesetzt, werden jedoch wesentlich mehr Daten gesammelt und gespeichert. Der Performance Monitor sollte nach möglichkeit zu der zeit laufen wo Engpässe entstehen oder zu erwarten sind. Eine Erfassung über 2 Stunden ist normalerweise ein guter Wert.

• Der Performance Advisor

Für den Advisor und alle folgenden Auswertungen benöntigt man den Performance Tools Manager. Der Performance Advisor ist die einfachste Auswertung. Der Advisor prüft in erster Linie die Einhaltung der Guidelines und gibt ratschläge was zu tun ist. Der Advisor gibt keine hinweise auf Anwendungen und bezieht sich bei den Aussagen zu Jobs ausschließch auf interaktive Jobs. Man kann eigentlich nichts falsch machen, wenn man die Anweisungen der Advisors befolgt, es ist jedoch sehr oft auch möglich auf die Anschaffung neuer Hardware zu verzichten, wenn man nur einige Programme optimiert.

• Display Performance Data