Re: Performance Issue - Journal Wait Time -- MIDRANGE-L

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.