Re: Performance Issue - Journal Wait Time

[Charles Wilt <charles.wilt@xxxxxxxxx>]

Rob,

That LPP is the batch journal caching feature Kenneth mentioned.

Kenneth,

First off, if you're using commitment control, the batch journal caching
product doesn't matter...at least if you're committing close to 128KB (?)
or so of changes at once.

If you're committing only a handful of changes, then my first guess would
be that the journal cache got turned off.

You might take a look at the journal bundles that were done on both days...
http://www-03.ibm.com/systems/power/software/i/db2/support/code/journal-utilities.html

Some of the other journal tools may be helpful also.

Charles


On Tue, May 13, 2014 at 2:06 PM, <rob@xxxxxxxxx> wrote:

> I don't know exactly what this is:
> <snip>
> Note: We do have the Batch Journal Caching feature installed and turned
> on.
> </snip>
>
> I will say that adding this LPP:
> Resource
>    ID     Option  Feature  Description
> 5770SS1   42       5117    HA Journal Performance
> Made a huge difference in our journal performance!  A much bigger
> improvement than SSD's did.  And, at a much lower cost.
> And with the 70 day grace period before the license expired, what's to
> hurt?  Try and buy.  (Unlike SSD's)
> Took hours off of month end processing.  And we installed it just before
> month end to give us two month end runs to compare.
>
> Rob Berendt
> --
> IBM Certified System Administrator - IBM i 6.1
> Group Dekko
> Dept 1600
> Mail to:  2505 Dekko Drive
>           Garrett, IN 46738
> Ship to:  Dock 108
>           6928N 400E
>           Kendallville, IN 46755
> http://www.dekko.com
>
>
>
>
>
> From:   "Graap, Kenneth" <Kenneth.Graap@xxxxxxxxxxxxx>
> To:     "Midrange Systems Technical Discussion (midrange-l@xxxxxxxxxxxx)"
> <midrange-l@xxxxxxxxxxxx>
> Date:   05/13/2014 01:54 PM
> Subject:        Performance Issue - Journal Wait Time
> Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
>
>
>
> We run a big bill posting batch process every night.
>
> The main determining factor for how long this job runs is the number of
> bills being posted.
>
> Friday night this job posted around 35,000 bills and ran in 3.6 hours.
>
> Last night’s job posted around 35,000 bills and ran in 5.1 hours.
>
> This time of night, nothing else of any significances is running but this
> one posting job.
>
> As I dig into the performance data for these jobs, the main difference
> that pops out is that the job running 5.1 hours had a significant higher
> number of JOURNAL WAITS… This application does use commitment control and
> therefore a lot of application journaling is occurring, so I expect waits.
> I didn’t expect to see such a big increase though.
>
> In fact when I ran a journal analysis for this job, the amount of journal
> updates and deletes for the 2 main files in the process were very close to
> the same for both jobs… 6,300,000 updates and 1,400,000 deletes.
>
> Note: We do have the Batch Journal Caching feature installed and turned
> on.
>
> Journal  . . . . . . :   OCCISJRN        Library  . . . . . . :   P1FILES
>
> Attached receiver  . :   CIS1JR2026      Library  . . . . . . : JRNRCVCIS
>
> Text . . . . . . . . :   Production CIS Journal
>
> ASP  . . . . . . . . :   IASP1           Journaled objects:
> Message queue  . . . :   CISJRNMSGQ        Current  . . . . . :      23220
>   Library  . . . . . :     QGPL            Maximum  . . . . . :     250000
> Manage receivers . . :   *SYSTEM         Recovery count . . . :   *SYSDFT
> Delete receivers . . :   *NO             Receiver size options:   *MAXOPT3
> Journal cache  . . . :   *YES            Fixed length data  . :   *JOB
> Manage delay . . . . :   10                                       *USR
> Delete delay . . . . :   10                                       *PGM
> Journal type . . . . :   *LOCAL
> Journal state  . . . :   *ACTIVE
> Minimize entry data  :   *NONE
>
> That’s about as far as I’ve got… I can’t seem to find any reason for
> such a large increase in “Journal  Wait Time” for this job…
>
> Any ideas as to what might be going on would be greatly appreciated!
>
> Kenneth
> AKA … 肯尼思 or 케네스
> Kenneth E. Graap
> System Administrator
> 503.226.4211 x5537
> http://www.linkedin.com/in/kennethgraap
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
> list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.