RE: Performance Issue - Journal Wait Time

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