View Full Version : eingefrorene interaktive Jobs
Wir haben von Zeit zu Zeit das Problem, daß bei uns die Perfomance so sehr in den keller geht, daß unsere interaktive Jobs komplett einfrieren und teilweise erst 5min später reagieren. In der Zeit versuchen die user natürlich ne zweite Session zu starten, die dann vom System ebenfalls nicht bedient wird.
Mein erster Verdacht war mal der QDBFSTCCOL-Job, den ich zeitgleich bei WRKACTJOB habe sehen können. Aber da der Job mit jedem IPL gestartet und dann auch nicht mal im eingeschränkten Zustand beendet wird, finde ich keinerlei Daten dazu im QACGJRN, geschweige denn die Möglichkeit im Nachhinein herauszufinden ob dessen Ressourcenhunger da gerade zu groß war.
Ich vermute aktuell aber eher ein Problem mit unserer QINTER. Da sind 1500 Jobs drin..... kommt mir jetzt irgendwie ein bißchen zuviel vor. Oder kümmert sich QPFRADJ (steht bei uns auf 2=IPL&Automatik) da drum und ich muß mir keine Sorgen machen?Zumindest sollte der doch die Werte die man beim Befehl WRKSHRPOOL
sieht auch entsprechend angleichen.
Letztlich wäre nur die Pool-Zuordnung von QINTER relevant. Bitte berichtigt mich wenn ich da falsch liege.
Da steht in der Pool-Definition:
Speichergröße
Pool-ID (KB)
1 *BASE
2 *INTERACT
Sollte man nicht den *BASE-Pool daraus entfernen? Ich will ja schließlich nen separaten Pool Oder zumindest sowas wie eine Reserve.
Das deutet eher massiv auf ein Überschreiten der maximal zulässigen Dialog-CPW für deine Lizenz.
M.a.W., da bremst wohl ein CFINT-Job, der künstlich die Ressourcen auslastet.
Den CFINT sieht man wohl nur mit WRKSYSACT (Performancetools).
Aber es soll da was geben, wie man den CFINT lahmlegt, wende dich da mal an Holger.
Wie komme ich denn an die Information wieviel CPW wir zur Verfügung stehen haben?
Mein Chef weiß nix und den Task CFINT finde ich auch erst, wenn er aktiv ist.
Oder gibt es eine Methode im Nachhinein heraus zu finden, ob der aktiv war?
Logic IT-Services
02-05-12, 17:05
Hallo
Vielleicht hilft Dir der untenstehende Link.
http://www.gofaster.us/archivos/GoFasterStudio%20ENG.pdf
http://newsolutions.de/forum-systemi-as400-i5-iseries/system-i-hauptforum/8855-cpw-einer-iseries-maschine-herausfinden.html
Uebrigens:
Web-Anwendungen mit RPG OA sind davon nicht betroffen, da diese im QHTTPSVR Subsystem laufen.
Batchprogramme sind generell davon nicht betroffen!
holgerscherer
02-05-12, 18:50
Wie komme ich denn an die Information wieviel CPW wir zur Verfügung stehen haben?
Mein Chef weiß nix und den Task CFINT finde ich auch erst, wenn er aktiv ist.
Oder gibt es eine Methode im Nachhinein heraus zu finden, ob der aktiv war?
Im Nachhinein ist es schwierig, wenn nicht ständig eine Performance-Überwachung läuft.
Wie schon geschrieben:
- WRKSYSACT (falls Performance-Tools installiert) kann CFINTxx Jobs anzeigen, die bei Erreichen der erlaubten (!) Interaktivleistung das System bremsen.
- WRKACTJOB (wenn CPU=100% und Summe der Jobs bei Weitem nicht bei 100%, dann -> IBM-Sperre)
Poste mal folgendes:
- DSPSYSVAL QMODEL
- WRKHDWRSC *PRC
Ansonsten bei Bedarf anrufen, wenn das Problem auftritt. Dann findet man die Ursache am einfachsten.
-h
Wir haben eine IBM Power 750 Express (8233-E8B) mit 8 Prozessoren(Featurecode EPA3). 2 davon sind für die beiden VIOs dediziert, die anderen 6 für den Shared Pool, die dann alle für die einzige aktive LPar (ebenfalls 6 virtuelle Prozessoren) geht.
6TB Platte aus dem SAN und 96GB Hauptspeicher.
Nur finde ich leider keinerlei Informationen dazu im Web.
WRKSYSACT bzw. PerformanceTools sind isntalliert, und das Problem scheint immer nur zur Monatsabrechnung aufzutreten.
Sammeln die performanceTools denn Angaben über den CFINT-Task? Und wenn ja wie kann ich die herausfinden?
QDBFSTCCOL ist schon ein Kandidat, da gab es bereits mehrfach PTFs zu, um den Ressourcenfraß in den Griff zu bekommen.
D*B
Bei der Größenordnung sollte CFINT eigentlich keine Rolle spielen, 1500 Jobs sind da doch gar kein Problem.
Hier ist dann tatsächlich ein bestimmter Job als Ressourcenfresser der Grund.
Wenn der Fall dann auftritt, muss man mal die Gesamt-CPU-Auslastung betrachten und ob die ausgebremsten Dialogjob's nicht auf Sperrfreigaben warten, also nicht durch CFINT gebremst werden.
Per WRKACTJOB kann man die Spalte CPU mal sortieren, so dass der größte Ressourcenfresser schnell gefunden wird.
Man kann per WRKSYSSTS z.B. die Zahl "Aktiv->n.Wählbar" betrachten.
Dieser Wert sollte eigentlich immer auf 0 stehen. Ist dieser größer 0 gibt es tatsächlich Ressourcenengpässe (Hauptspeicher), da ein als aktiv gekennzeichneter Job mangels Speicher nicht ausgeführt werden kann.
Ich wollte gerade sagen, daß unsere PTFs erst Anfang April alle aktualisiert wurden - da sehe ich daß ausgerechnet die HyperV-Gruppe am 24.4. wieder upgedatet wurde. Und natürlich mit IPL - ich hasse sowas...
Immerhin sieht's nicht so aus, als hätten die Fixes Einfluß auf den QDBFSTCCOL.
Bis unsere DAUs mal anrufen, ist das Phänomen oft weg und dann sind wir alle wieder bei braven 40% Auslastung. Auch der nicht wählbare Speicher ist auf 0. Bei 7000Jobs im System bleibt eben immer die Frage, wie aussagekräftig die Prozentwerte sind. Manch ein regulärer Job zieht sich auch mal 8%, was im allgemeinen recht hoch ist. Da endet ein Nachrechnen bei gröbsten Rundungsfehlern.
Von diversen QZDASOINIT und überhaupt zahllosen ungezügelten "Power"-Usern mit excessiven SQL-Abfragen etc. mal ganz zu schweigen. Teils dürfen die sogar Journals erstellen... Absolutes Chaos.
Mein Problem ist eben, ich muß das irgendwie Eingrenzen/Bestimmen was es genau ist um entsprechend tätig werden zu können. Ich brauche im Endeffekt Fakten, mit denen ich Maßnahmen auch rechtfertigen kann.
Vorab schon mal Euch allen Danke für Eure Hilfe. Ich hoffe jetzt drauf, daß es entweder CFINT, QDBFSTCCOL oder irgendein anderes identifizierbares Problem ist.