Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

QZDASOINIT Performance V5R3

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • QZDASOINIT Performance V5R3

    We recently implemented a Web Application that uses ODBC to access our data.
    The QZDASOINIT run at very high cpu that impacts our nightly production batch.
    I would like to change the QUSRWRK Subsytem and add *SHRPOOL2, and remove *BASE.
    Then allocate a fixed amount of memory to *SHRPOOL2 to keep the jobs formally running in *BASE from using up memory resources.
    Does anyone know which RGTE I need to change?


    Seq Nbr Program Library Compare Value Pos
    10 QCMD QSYS 'RUNPTY07' 1
    20 QCMD QSYS 'RUNPTY10' 1
    30 QCMD QSYS 'RUNPTY20' 1
    40 QCMD QSYS 'RUNPTY25' 1
    50 QCMD QSYS 'RUNPTY35' 1
    60 QCMD QSYS 'RUNPTY50' 1
    2210 QSCWCMON QSYS 'WATCHEVENT' 1
    2211 QSCLICEV QSYS 'WATCHLICEVENT' 1
    9999 QCMD QSYS *ANY

    So it only uses *SHRPOOL2.
    My first guess would be number 30 because our just are running at PTY(20).
    Maybe someone here can make some suggestions.

    Thanks,
    Keith

  • #2
    You can use iSeries Navigator to separate all QZDASOINIT jobs (Host server - Database server of i5/OS) into another subsystem. Instructions on page 3-16 of this paper would be useful for you: iSeries Experience Report: Subsystem configuration at http://publib.boulder.ibm.com/infoce...k1abstract.htm.

    As for CPU consumption of QZDASOINIT, you should raise the run-time priority of your batch jobs to let them better compete for CPU cycles with QZDASOINIT.

    Once you separate QZDASOINIT from *BASE pool, you should start Collection Services in iSeries Navigator and specify the retention period of at least about 5-7 days and use Graph History to monitor nightly resource utilization to help you get an idea how they are utilized between your production batch jobs and QZDASOINIT jobs.

    Did you also create useful indexes for various statements that QZDASOINIT to help them finish their jobs as fast as possible and thus do not adversely affect your batch jobs' run-time?
    Last edited by satid; 06-14-2009, 09:30 PM.

    Comment

    Working...
    X