IO_WTIME

Ansicht von 3 Beiträgen - 1 bis 3 (von insgesamt 3)
  • Author
    Posts
  • 28. August 2007 um 9:00 Uhr #2800

    Anonym
    Inaktiv

    Wir 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

    Anonym
    Inaktiv

    Hi 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

    Anonym
    Inaktiv

    Hallo 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

  • Author
    Posts
Ansicht von 3 Beiträgen - 1 bis 3 (von insgesamt 3)

You must be logged in to reply to this topic.