IO_WTIME
- Dieses Thema hat 2 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 16 Jahren, 10 Monaten 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
Gernot3. 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.