Hallo,

Ferndiagnosen sind meist schwierig, aber trotzdem ein paar Anmerkungen zu den zitierten Aspekten:

wenn du den "Klemmer" beobachtest, dann einfach in der Call Stack Anzeige so oft man es schafft refreshen und von dem aktiven Programm Hardcopys machen liefert eine statistische Verteilung der runtime Anteile (was anderes machen die Performance tools letztlich auch nicht. Wenn da einer 90 % hat -> et voila.

open of member was changed to seqonly riecht nach full table scan (ist in den reads nicht auffällig wg. Blockung und könnte Plattenaktivität plausibel erscheinen lassen.

mfg

Dieter Bender

Zitat Zitat von ChrisX Beitrag anzeigen
So, erstmal wieder Vielen Dank für die Informationen!

@jo400: Wenn diese probleme auftreten rufen mich die Anwender meist direkt an. Ich beobachte dann generell den job status. Es kam zwar vereinzelt mal vor, dass der Job ein kurzes Object Lock hatte (LCKW) aber dies war entweder kein Dauerzustand über die ganzen 5-6 Minuten noch habe ich das gefühl, dass mit den "kurz" auftretenden Lockwaits ein wirkiches problem besteht. Normalerweise hat der Job den Status RUN. Wenn ich in das Joblog schaue, sehe ich zum aktuellen Zeitpunkt (also wenn der Job hängt) meist nur den folgenden letzten Eintrag:

Open of member XXX was changed to SEQONLY(*NO).

Das ist meist der einzige Eintrag den ich sehen kann.

Die CPU Auslastung ist oft sehr schwankend, wobei die meiste CPU Zeit von BATCH Jobs mit PRIO > 20 gebraucht wird.

Meine Idee war, dass ich mit Hilfe des Call Stacks das Programm, welches aktuell "arbeitet" herausfinden kann um dann zu prüfen was dieses Programm genau macht und warum die Zeitverzögerung zustande kommt.

Laut Anwender wurde die performance über Monate hinweg immer schlechter.

Danke schonmal + Gruss
Chris