IO_WTIME
- Dieses Thema hat 2 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 16 Jahre von
Anonym.
-
AuthorPosts
-
28. August 2007 um 9:00 Uhr #2800
AnonymInaktivWir haben Performance-Probleme mit einem OPEN CURSOR in einer Online (CICS)-Anwendung.
Zum Vergleich haben wir denselben Cursor testweise in einem Batch-Progamm und in Spufi untersucht.
Ergebnis der Auswertung:
* Im Batch und im Spufi ist der OPEN CURSOR deutlich schneller als im CICS.* In allen drei Varianten (CICS, SPUFI, Batch) ist der Zugriffspfad (per EXPLAIN) identisch.
* Die ausgewiesene CPU-Zeit (INDB2_CPU mit dem Tool "Platinum Detector") ist in allen drei Umgebungen (CICS, Batch, Spufi) fast identisch.
* Die "INDB2_TIME" ist im CICS ca. 10 mal höher als im Batch bzw. im Spufi  🙁
* Im CICS werden 90% der INDB2_TIME als IO_WTIME ausgewiesen, im Batch bzw. Spufi ist die IO_WTIME vernachlässigbar.
Hat jemand einen Tipp, an welchen Parameter wir drehen können, um den Online-Zugriff so schnell wie die beiden anderen zu machen?
29. August 2007 um 17:28 Uhr #3182
AnonymInaktivHi Christoph,
hast Du mal den Bufferpool angeschaut, durch den die Pages des Objects geschleust werden? Ist er groß genug? Gibt es viel Sync I/O.
Auf dem DB2, auf dem ich arbeite, werden DISPLAY BUFFERPOOL INTERVAL morgens um 07:00 (nach Batch) und um 19:00 (nach Online) ausgeführt und ausgewertet. Der Output ist sehr aufschlußreich!
Wie sehen die Threshold Einstellungen des Bufferpools aus, und wie sieht VPSIZE aus?
Viele Grüße
Gernot
3. September 2007 um 12:40 Uhr #3435
AnonymInaktivHallo Gernot,
vielen Dank – der Hinweis auf den Bufferpool war sehr hilfreich.
Der Unterschied der "IO_WTIME" zwischen den drei Umgebungen lässt sich ziemlich genau durch die unterschiedliche Anzahl der "synchronen reads" (bei gleicher Anzahl von GETPAGES) erklären.
Viele Grüße
Christoph
-
AuthorPosts
You must be logged in to reply to this topic.