Re: Performance Issue - Journal Wait Time

Maybe yes...Maybe no :)

Do you think soft commit may have been turned on before and gotten turned
off?

The utilities I provided a link too should be able to confirm that.

Sue's point about disk ops is something else to look at.

Charles


On Wed, May 14, 2014 at 1:38 PM, Graap, Kenneth <Kenneth.Graap@xxxxxxxxxxxxx

wrote:

I think I may have found out what is happening with journaling in my
environment... I'm going to give this a try!

Excerpts taken from the "Four Hundred Guru, May 14, 2014" (In my case, a
very timely article on Journal waits!!!)

According to IBM i expert Gary Patterson, commitment control is set up to
flush journal entries to disk, regardless of caching or bundle size."
Commitment control breaks journal caching by putting your job back into the
journal wait state that journal caching is designed to avoid.

Fortunately, there is a fix. You can turn on a "soft commit" for an
individual job or for your entire system, and that will enable you to
continue using journal caching for batch jobs.

Commitment control, by default, and intentionally, breaks journal caching.

COMMIT operations, by default, cause journal management to flush journal
entries to disk, regardless of caching or bundle size. As a result, it is
not uncommon, especially in high-volume batch programs that use commitment
control, to see a lot of cumulative journal waits unless the developer
understood the impact of COMMITing too frequently and was careful to ensure
an adequate journal bundle size.

The traditional fix for this problem is to have the developer to change
the application to COMMIT less frequently. Developers sometimes don't like
to hear that, since it can cut into their long lunches and involve tedious
things like change control forms, specifications documents, approvals,
funds authorizations - oh - and some small amount of actual coding and
testing.

It can also requires some repetitive testing to determine the optimal
bundle size.

I know from experience that the optimal bundle size has grown larger over
the years, so hard-coding is out. If you only COMMIT every 20th transaction
today, after your next upgrade the optimal bundle size may take 40
transactions. So then you'll start to see journal waits again, and you have
to do some testing to figure out the optimal bundle size.

Soft Commit - journal caching for batch programs

Wouldn't it be nice if you could choose to turn on journal caching for
batch commitment control applications? Maybe not on a system-wide basis.
You might have some critical applications that just must be allowed to
flush every journal entry to disk for replication or audit purposes, but
for the majority of applications, caching would be just the ticket.
And you can. Starting in V5R4, IBM offers "soft commit" support using the
environment variable QIBM_TN_COMMIT_DURABLE. By turning OFF Durable
commits, you ENABLE soft commits. You can set this environment variable at
either the system level so it applies to all jobs on the system, or at the
job level.

Just a note: if you set an environment variable at the *JOB level, it
doesn't get copied down to child jobs submitted by the parent job by
default. If your parent job submits child jobs, you'll want to specify
CPYENVVAR(*YES) on each SBMJOB or add the ADDENVVAR command to each job in
the job stream.

ADDENVVAR ENVVAR(QIBM_TN_COMMIT_DURABLE) VALUE(*NO) LEVEL(*JOB)

In a nutshell, "soft commit" allows batch jobs to use journal caching.
That's it. Turn on soft commit, and then COMMIT as early and often as you
like. Journal management will ignore those CM journal entries, and wait
until a healthy bundle size has been reached, and then flush then entire
bundle to disk in one large, efficient operation.

Reply or Forwarded mail from: Kenneth E Graap

--
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.