Mal wieder Performance

[KingofKning]

Hallo *all,
in unserem Warenwirtschaftssystem können wir div. Listen im Batch abrufen. Ich sehe den Job auch fröhlich im Qbatch mit so 1,0 bis 1,2% CPU. Während des laufs macht er ca. 2443 Aux-IOs innerhalb von 10 Sekunden. Der ganze Job läuft über eine Stunde!!
Bei den angezeigten Dateien kann ich auch keine LCKWs sehen, wäre für eine reine Auswertung auch ungewöhnlich, aber die Liste kommt nicht aus den Socken.
Leider habe ich keinen Zugriff auf die Sourcen so das ich nicht sehen kann was er wirklich liest und evtl. verwirft.
Stutzig macht mich halt nur das die CPU nur bei 1,0 liegt und bei wrksysact liegt die Overall DB CPU util locker bei 0,0 nur wenn einer der Kollegen was startet sehe ich das die DB auf 20% geht.

Gibt es eine Möglichkeit für mich den Flaschenhals zu finden oder ist das nur dem Programmierer möglich?

GG

[andreaspr@aon.at]

Das wäre wieder so ein Fall für den DB-Monitor.
Am einfachsten kannst du den über den Navigator starten - beenden - analysieren.

lg Andreas

[Fuerchau]

Ob der DB-Monitor da hilft?
250 IO's/Sekunde ist da nicht so viel. Theoretisch geht da mehr.

Allerdings sagt die Anzahl IO's nichts über die Anzahl Sätze aus da beim Lesen ja durchaus auf 32KB geblockt wird. Je nach Satzlänge kann ein IO also durchaus mehrere Sätze beinhalten.

Das Problem liegt hier ggf. an der verwendeten Arbeitsdatei (QTEMP?).
Ich habe es schon häufig erlebt, dass Arbeitsdateien mit FRCRATIO(1) angelegt und so auch in die QTEMP kopiert werden. Dies führt natürlich zu erheblichen Einbußen, da beim Schreiben erzwungenermaßen jeder einzelne Satz direkt auf die Platte geschrieben werden muss.
Es gibt keinerlei Gründe für FRCRATIO(1) insbesonders in so einem Fall.

Beim Imfor-XPPS z.B. habe ich viele Arbeitsdateien auf FRCRATIO(*NONE) gestellt und die Batchjobs wurden z.T. erheblich schneller fertig.
Laufzeiten von über 1 Stunde auf unter 5 Minuten!

[KingofKning]

Ob der DB-Monitor da hilft?
250 IO's/Sekunde ist da nicht so viel. Theoretisch geht da mehr.


Das Problem liegt hier ggf. an der verwendeten Arbeitsdatei (QTEMP?).
Ich habe es schon häufig erlebt, dass Arbeitsdateien mit FRCRATIO(1) angelegt und so auch in die QTEMP kopiert werden. Dies führt natürlich zu erheblichen Einbußen, da beim Schreiben erzwungenermaßen jeder einzelne Satz direkt auf die Platte geschrieben werden muss.
Es gibt keinerlei Gründe für FRCRATIO(1) insbesonders in so einem Fall.

Kann ich das im laufenden Job feststellen?
GG

[Fuerchau]

Prüfe, welche Dateien upgedatet oder geschrieben werden und per DSPFD die FRCRATIO.

[Logic IT-Services]

Soeben wieder mal selbst erlebt...
Kann es sein, dass die Listen mit Joins und DYNSLT verabeitet werden?

QAQQINI lässt grüssen.

[Fuerchau]

Dann wäre allerdings die CPU-Last am Anfang ungleich höher da auch hier ggf. intern erst ein Index aufgebaut wird.
Nach dem Open geht das Lesen dann allerdings sehr schnell.

[KingofKning]

Tja, so wie ich das sehe wird direkt in die Spooldatei geschrieben ohne Sortierdatei in Qtemp oder so. Heißt er muß dann für jeden einzelnen Datensatz tausende andere überlesen.

Was mich halt wundert ist das die CPU Auslastung so gering ist.

GG

[holgerscherer]

Tja, so wie ich das sehe wird direkt in die Spooldatei geschrieben ohne Sortierdatei in Qtemp oder so. Heißt er muß dann für jeden einzelnen Datensatz tausende andere überlesen.

Was mich halt wundert ist das die CPU Auslastung so gering ist.

GG

Sortierdateien in QTEMP - das war damals, vorm Kartoffelkrieg ;-)

Die CPU-Auslastung kann aus folgenden Gründen gering sein:
- hohe Plattenlast (hatten wir ja nicht)
- häufige Jobwechsel (Aktivitätslevel, Speicherpoolgröße)
- häufige open/close Operationen
- locking conditions
etc...

solang Du nicht weisst, was im Programm so genau abgeht, ist das alles nur Raterei. Tracen, Debuggen, oder im wrkactjob den Callstack beobachten mit häufiger Aktualisierung. Ansonsten brauchen wir Glaskugeln

-h

[BenderD]

... das ist rein akademisch, da man ohne Quelle das Problem eh nicht beheben kann.
Als erstes wären Jobstart und Completion message interessant - die weisen Laufzeit und verbrauchte CPU aus. Dann könnte man sich mal den callstack mit mehrfachem Refresh ansehen und die geöffneten Dateien mit mehrfachem refresh; Database Monitor hilft wahrscheinlich nix, das riecht nach Rekord Löffel Ekzem...

D*B

Hallo *all,
in unserem Warenwirtschaftssystem können wir div. Listen im Batch abrufen. Ich sehe den Job auch fröhlich im Qbatch mit so 1,0 bis 1,2% CPU. Während des laufs macht er ca. 2443 Aux-IOs innerhalb von 10 Sekunden. Der ganze Job läuft über eine Stunde!!
Bei den angezeigten Dateien kann ich auch keine LCKWs sehen, wäre für eine reine Auswertung auch ungewöhnlich, aber die Liste kommt nicht aus den Socken.
Leider habe ich keinen Zugriff auf die Sourcen so das ich nicht sehen kann was er wirklich liest und evtl. verwirft.
Stutzig macht mich halt nur das die CPU nur bei 1,0 liegt und bei wrksysact liegt die Overall DB CPU util locker bei 0,0 nur wenn einer der Kollegen was startet sehe ich das die DB auf 20% geht.

Gibt es eine Möglichkeit für mich den Flaschenhals zu finden oder ist das nur dem Programmierer möglich?

GG