Interaktive CPW erschöpft?

[RobertPic]

Wir haben hier eine iSeries Model 820, P20 mit 250 Batch + 120 Interaktiv CPW.

In letzter Zeit werden die 5250-Sessions langsam. Wenn man einen WRKACTJOB anwirft (was dann aber dauert..) bekommt man meist nicht mehr als 60-70% angezeigt.

Ich habe daher den Verdacht, dass die interaktiven CPW aufgebraucht sind. Daher meine Fragen:

- Gibt es irgendwo eine Meldung wenn die interaktiven CPW erschöpft sind?
(im QHST habe ich nichts gefunden)

- Verwendet er vielleicht doch auch Batch-CPW's? Den bei den interaktiven Funktionen (im PM/400) geht er auch über 100%.

- Wo sehe ich, wieviel im Moment von den interaktiven CPW's benötigt werden. Sind das die "interaktiven Funktionen" im PM/400? Laut Hilfe könnte das hinkommen.

Jetzt habe ich mal den Perfomance Monitor angeworfen und lese mich gerade in die Redbooks ein - aber das kann noch etwas dauern...

Robert

[Miggi]

CPI1479 - Interaktive Auslastung nähert sich der Kapazitätsgrenze des installierten Features.

Diese Nachricht erhält man wenn 90% der interaktiven Auslastung der erreicht sind.
Tritt dieser Fall ständig auf, sollte man laut Big Blue auf das nächst höhehre interaktive Feature umsteigen. Aber das kann ja keiner bezahlen...

Batchprozesse sind von der interaktiven Leistung nicht betroffen, außen Sie schnappen sich von der CPU so viel weg, dass für interaktiv nicht viel übrig bleibt.
Das dürfte aber erst so ab 80% passieren.

Gruß Miggi

[pwrdwnsys]

Schau dir doch mal im WRKSYSSTS die Paging-Raten an. Meist sind nur die Pools falsch eingestellt (passiert leider auch bei der automatischen Anpassung) und dadurch kann der prozessor nicht arbeiten, weil nichts zum Abarbeiten zur Verfügung steht.

Interessant ist die Spalte "Nicht DB fehl." Wenn der Wert > 20 ist, dann wird die Maschine recht langsam.

Hauptspeicher ist durch nichts zu ersetzen. Es sei denn durch noch mehr Hauptspeicher.

[RobertPic]

Danke einmal für die Antworten.

Nachdem ich keine CPI1479 im QHST finden kann, schaut es nicht nach einem Engpass der Interaktiver CPW aus.

Interessant ist die Spalte "Nicht DB fehl." Wenn der Wert > 20 ist, dann wird die Maschine recht langsam.

Welcher Wert zählt hier? Der bei der 1. Anzeige, nach F5 oder nach F10 + F5?
Welcher Zeitraum?

Ich habe hier zwar Werte deutlich über 20, aber die habe ich auf einer anderen Maschine auch (wenn ich länger nicht mit F10 zurücksetze).

Definitiv einen Engpass gibt es bei den Platten. Hier rächen sich die unterschiedlichen Größen. Die 2 größeren 17GB-Platten dürften wohl der Bremsfaktor sein (beim letzten "Schläfchen" auf 99%). Wobei die 8GB Platten mit knapp 90% (beim "Schläfchen") auch schon bedient sind.

Die Backupplatten der Spiegelung tümpeln bei 16-20 % herum.

Der Austausch der Maschine ist für nächstes Jahr geplant. Mal sehen, ob sich das ausgeht.....

Jetzt gilt es nur noch rauszufinden, wieweit ein RAM-Mangel dafür schuld ist.

Robert

[holgerscherer]

Danke einmal für die Antworten.

Nachdem ich keine CPI1479 im QHST finden kann, schaut es nicht nach einem Engpass der Interaktiver CPW aus.

Kommt auf Dein Release an, die Meldung gibt es erst seit IMHO V5R1. Schau mal, ob Du die Performance Tools 5722PT1 installiert hast, wenn nicht, nutze wenigstens die Karenzzeit, damit Du mit WRKSYSACT siehst, ob der CFINT hochkommt.
Alternativ: Mach ein WRKACTJOB, F10, Blick auf die CPU-Anzeige an der Maschine vorne, und nach 20 Sekunden F5. Wenn die CPU-Anzeige die ganze Zeit oben war, im WRKACTJOB aber weniger angezeigt wird, riecht das auch gerne nach CFINT.

Beim WRKSYSSTS suchst Du Dir auch einen Zeitraum, in dem viel los ist. Zunächst mit F10 zurücksetzen, dann nach - sagen wir - einer Minute mit F5 aktualisieren. Wenn jetzt die Fehlerseiten über 20 sind, sollte man sich über Hauptspeicher zumindest Gedanken machen. Parallel dazu mit WRKDSKSTS schauen (gleiche Methode, F10, etwas warten, F5) wie stark die Platten verwendet sind (letzte Spalte). Wenn da über längeren Zeitraum über 20% angezeigt werden, ist es schon interessant. Je nach Platte kann man das aber nicht pauschal sagen. Schau Dir in dem Zeitraum lieber mal die Anzahl der E/A-Anforderungen an. Je nach Plattenmodell und Controller sind die Grenzen unterschiedlich.

Richtwerte:
6713 max 40
6714 max 80
6717 max 55
6718 max 90
etc...

Ich habe hier zwar Werte deutlich über 20, aber die habe ich auf einer anderen Maschine auch (wenn ich länger nicht mit F10 zurücksetze).

Im WRKSYSSTS? Dann wirf ein paar Gigabytes RAM rein.

Definitiv einen Engpass gibt es bei den Platten. Hier rächen sich die unterschiedlichen Größen. Die 2 größeren 17GB-Platten dürften wohl der Bremsfaktor sein (beim letzten "Schläfchen" auf 99%). Wobei die 8GB Platten mit knapp 90% (beim "Schläfchen") auch schon bedient sind.

Urgs, im WRKDSKSTS? Dann ist die Maschine nur noch mit sich selbst und den Platten beschäftigt... da helfen auch keine Tools mehr.

-h

[RobertPic]

Kommt auf Dein Release an, die Meldung gibt es erst seit IMHO V5R1. Schau mal, ob Du die Performance Tools 5722PT1 installiert hast...

Wir haben V5R2 und den Performance Monitor installiert. Ich habe ihn mittlerweile sehr fleißig benutzt. Als "Highlight" hatte ich einmal 100% maximale Plattenarmlast für 10 Minunten - bei 60 % CPU Auslastung.

Beim WRKSYSSTS suchst Du Dir auch einen Zeitraum, in dem viel los ist. Zunächst mit F10 zurücksetzen, dann nach - sagen wir - einer Minute mit F5 aktualisieren. Wenn jetzt die Fehlerseiten über 20 sind, sollte man sich über Hauptspeicher zumindest Gedanken machen.

Werde ich beim nächsten mal machen. Die Ausreißer bei den Fehlseiten gibt es im PM/400 weniger - leider trennt der nicht nach Pool.

Mich irritiert, dass die Batchjobs so einigermassen gelebt haben. Wir der Hauptspeicher schlecht verteilt?

Richtwerte:
6713 max 40
6714 max 80
6717 max 55
6718 max 90

Wir haben die 6717 (8GB) und 6718(17GB).

"Leider" gibt es das Problem nicht immer zu bewundern - die genauen Fehlseiten werde ich erst beim nächsten "Schläfchen" haben. Aber Montag wird es schon wieder rundgehen..

Danke für die Infos

Robert

[BenderD]

Hallo Robert,

Ferndiagnosen sind da immer schwierig (zumal wenn man wie ich, nach Meinung eines Herren, ja keine Ahnung hat...)

Das mit den Batchjobs, wenn die so geschrieben sind, wie man früher bei uns Speis gemacht hat, einen Haufen von links nach rechts schippen und wieder zurück, bis alles vermischt ist (Datei sequentiell lesen, andere Werte per chain lesen, ein wenig verbasteln und wieder schreiben, eventuelle in mehreren Durchgängen), dann haben diese Jobs folgende Charakteristik: sie brauchen wenig Speicher gleichzeitig, um zu laufen, alles was sie am Wickel hatten interessiert sie danach nie wieder, sie werden durch nix und niemand unterbrochen, solche Jobs sind vom paging so gut wie nicht tangiert.

Interessant finde ich das Phänomen hohe Plattenlast über 10 Minuten bei 60% CPU, wenn das vom paging käme, das verbraucht ebenfalls CPU. Ich würde doch nochmal die CFINT Aktivität als Auschluss Diagnose empfehlen und bist du sicher, dass da nicht sone write cache Batterie das Problem macht?

mfg

Dieter Bender

Mich irritiert, dass die Batchjobs so einigermassen gelebt haben. Wir der Hauptspeicher schlecht verteilt?

Robert

[RobertPic]

@DieterBender: die von dir beschriebene Charakteristik trifft nicht nur auf das machen der Speis, sondern auch auf unsere Batchjobs zu.

@all

 % CPU benutzt  . . . . . :       36,5    Zusatzspeicher:                      
 % DB-Kapazität . . . . . :       13,2      System-ASP . . . . . . :    69,45 G
 Abgelaufene Zeit . . . . :   00:05:27      % System-ASP benutzt . :    75,8316
 Jobs im System . . . . . :       7597      Gesamtsumme  . . . . . :    69,45 G
 % perm. Adressen . . . . :      0,036      Unges. Platz akt.                  
 % temp. Adressen . . . . :      0,518        belegt . . . . . . . :     7323 M
                                            Max. ungeschützt . . . :     7471 M
 Änderungen (falls zulässig) eingeben und die Eingabetaste drücken.            
                                                                               
                                                                               
 System    Pool-    Reserv.    Max.  -DB-Seiten--  --Nicht-DB--                
  Pool   Größe(M)  Größe (M)  Aktiv  fehl.  geles  fehl.  geles                
    1      157,07     71,58   +++++    0,0    0,0    3,6    5,1                
    2      301,10      0,76      59    0,5    3,0    3,7    9,3                
    3      497,57      0,03      22   21,1   81,5   97,0  285,7                
    4       57,57      0,00       8    0,1    0,5    5,5   17,3      

Das ist ein WRKSYSSTS, F10 eine Minute warten F5.
Angesichts dieser Zahlen, frage ich mich, ob (wie pwrdwnsys vermutete) hier der Hauptspeicher falsch verteilt wird.

Anzumerken noch: Alle Arbeiten auf der Maschine gehen zum Zeitpunkt dieser Messungen schnell, PM/400 weist 0,4 als durchschnittliche Antwortzeit aus.

Ich habe mal auf Verdacht die Javaservicejobs ausgelagert (1 JVM, 14 Threads --> 50-60MB temporärer Speicher) --> brachte keine Besserung.

Da die andern Pools gut ausschauen, schaut die Fehlerseitenstatistik im PM/400 (alle zusammen) nicht so schlecht aus.

Ich habe die Messerung mehrmals wiederholt --> Fehl-DB im interkativen Pool immer um die 100.

Versagt hier die Automatik? Wo kann man die "Faustregel 20" nachlesen?

[holgerscherer]

Versagt hier die Automatik? Wo kann man die "Faustregel 20" nachlesen?

Die Automatik sollte man mit WRKSHRPOOL einschalten (Paging-Definition auf *CALC für Pools >1).

Auf jeden Fall ist der Pool 3 zu klein. Die prozentuale Plattenbelegung ist auch hart an der Grenze. Pool 1 könnte vielleicht 50% abgeben (mit vorsicht zu geniessen), Pool 2 ist (aus dem Bauch gesagt) auch "recht gut" dimensioniert. Wirf ein GB RAM rein, das ist nicht soo teuer, und wird hier meines Erachtens schon einiges bringen.

Übrigens... sobald ich die Worte "820er (klein)" und "Java" in einem Satz lese, braucht man über Performanceprobleme nicht weiter zu diskutieren (gd&r)...

Viele Grüße,
Holger

[RobertPic]

Die Automatik sollte man mit WRKSHRPOOL einschalten (Paging-Definition auf *CALC für Pools >1).

Ich bin immer davon ausgegangen, dass alle Anpassungen auf Automatik sind. Jetzt habe ich im WRKSHRPOOL gesehen, dass das Anpassen der Richtlinien auf *FIXED (alle Werte auf Default) stehen.

Ich werden den morigen Tag mit *CALC starten und den (eher schwachen) Vormittag beobachten.

noch Aufgefallen: *BASE hat Priorität 1, *INTERACT 2. Auf einer neueren 810'er (2GB Ram, 1000CPW ohne Int-Limit) sind die Prioritäten vertauscht (ebenfalls Defaultwerte).

Übrigens... sobald ich die Worte "820er (klein)" und "Java" in einem Satz lese, braucht man über Performanceprobleme nicht weiter zu diskutieren (gd&r)...

Wie gesagt, ich habe die Javadienste bereits auf eine andere Maschine ausgelagert (eine Propertie-Datei ändern und das wars, versuch das mal mit anderen Programmen).
ABER: Keine Änderung der Fehlerseiten oder der Poolaufteilung.

Ich behaupte sogar, dass bestimmte Arbeiten (z.B. alle 2 Sekunden ein FTP-Verzeichnis abfragen) mit Java resourcenschonender erledigt werden, als mit Boardmittel.

mfg
Robert

[BenderD]

Hallo Robert,

die "Faustregel" ist Hardware abhängig, in erster Linie vom Prozessor und mittlerweile weitgehend zurück gezogen (Quelle: Performance Capabilities Reference); mittlerweile werden nur noch Zahlen für den Machine Pool (da kommen die ominösen 20 her, waren mal 10) und für die Summe aller Faults genannt.
Hintergrund der ganzen Sache ist folgender:
Der Machine Pool sollte eigentlich garkeine Faults haben, weil alles was darein gehört Speicher resident sein sollte, weil garkeine nicht geht, nennt man hier eine kleine Zahl, die bei dir klar unterschritten wird.

Die anderen Pools haben notgedrungen Faults, es sei denn der gesamte single level store wäre Hauptspeicher resident. Probleme werden in der WRKSYSSTS Anzeige sichtbar, wenn sich die Jobs überwiegend mit paging beschäftigen; dafür muss man neben den paging Raten die Anzahl der konkurrierenden Jobs (activity level) berücksichtigen. Wenn zum Beispiel 500 interaktive Jobs pro Sekunde 100 page faults auslösen, dann wären das 0,2 faults per Job in einer Sekunde und das wäre ein guter Wert, sind es nur 50 Jobs, dann wären das 2 faults pro Job in der Sekunde und das wäre bedenklich. Hier sind guidelines zu finden, die Werte zwischen 0,25 und 0,5 faults pro Job in der Sekunde als Grenze nennen. In deinem Fall tendiere ich dazu, dass du den Flaschenhals wahrscheinlich noch nicht gefunden hast.

Am Rande sei noch erwähnt, dass PM400 kein sehr taugliches Instrument darstellt, das fällt mehr in die Kategorie Marketing, sei es in dem Sinn, dass hier Informationen geholt werden um Maschinenbestellungen zu generieren, oder dass ein EDV Leiter schöne Bildchen vorzeigen kann, wie toll die AS400 funktioniert.

mfg

Dieter Bender

PS: Mit Speis meint der Hesse das, was in manchen weniger zivilisierten Gegenden zuweilen mit Mörtel bezeichnet wird, also eine Mischung aus Sand, Wasser und Kalk oder Zement

Versagt hier die Automatik? Wo kann man die "Faustregel 20" nachlesen?

[RobertPic]

Hallo Dieter,

danke für das richtige "Stichwort" (Performance Capabilities Reference) jetzt bin ich da wo ich hinwollte: Formeln & Fakten.

Normalerweise finde ich bei der IBM alles, aber mit den "rückübersetzten" Begriffen von WRKSYSSTS, PM/400 & Co. hatte ich diesmal kein Glück.

Wenn zum Beispiel 500 interaktive Jobs pro Sekunde 100 page faults auslösen, dann wären das 0,2 faults per Job in einer Sekunde und das wäre ein guter Wert..

In meinem Fall sind es über 500 interkative Jobs. Wenn ich die Formel aus dem "Workmanagment" anwende, liege ich klar im grünen Bereich. (mit Zahlen von normaler Vollast - ohne Stehzeiten)

In deinem Fall tendiere ich dazu, dass du den Flaschenhals wahrscheinlich noch nicht gefunden hast.

Wie schon weiter oben geschrieben, wenn die Maschine Feierabend macht, stehen die 2 größeren 17GB-Platten auf 100% bis der Spuck vorbei ist.

Mir war nur nicht klar, ob das Swappen der Hauptverursacher oder nur ein Mitverursacher war.

Derzeit haben wir eine Plattenbelegung von 69%-75% (morgens-abends). Ich denke, dass ich das auf 61-67% bringen kann. Mal sehen, ob das was bringt.

Nach einem Plattentausch (einer der vier 17GB-Platten) und dem Stellen auf *CALC im WRKSYSSTS bzw. WRKSHRPOOL haben wird die letzte Stosszeit (Mon-, Dienstag 16-17 Uhr)
gut überstanden - aber das Ding schläft ja nicht jede Woche.

Robert

PS. Die Speis bestelle ich dann besser doch nicht im Gasthaus, falls ich mal in der Gegend bin. Grüße aus der "wilden" Steiermark, wo der Mörtel noch Mörtel heißt.