The IBM i Journal Cache Sweeper Knob

May 28, 2014 Joe Hertvik

After publishing my latest article on improving IBM i journal performance with journal caching, IBM Rochester Software Engineer Chad Olstad wrote in with the following comment, which expands on journal caching and offers an alternate view of journal caching’s relationship with commitment control.

“I wanted to point out the one thing you did not mention in the article is the cache sweeper knob, which controls how [old] stale cached journal entries are allowed to be before they are flushed to disk. [The cache sweeper knob] can be customized by the user as of V6R1 via [the Change Journal Attributes command,] CHGJRNA CACHEWAIT(nn), where nn is the number of seconds of journal entries the customer is willing to lose if they were to crash.”

After getting Chad’s email, I checked out the Change Journal Attributes command by typing in CHGJRNA and pressing the F4 key, which produced the following screen.

The Cache wait time (CACHEWAIT) parameter is the journal caching piece that Chad is referring to. CACHEWAIT is the maximum number of seconds that an IBM i system will wait before writing “stale” cached journal entries from memory to disk (flushing the cache). The benefit here is that you can tweak CACHEWAIT to either write cached journal entries to disk at a faster rate (decrease the value) or at a slower rate (increase the value).

The system default value for CACHEWAIT is 30 seconds. But there are some specific rules that you must be aware of for on CACHEWAIT to work.

The CACHEWAIT parameter is a global parameter. It affects all journals that have journal caching enabled. Journals that aren’t using journal caching will not be affected by this parameter. CACHEWAIT only affects how cached journal entries are written to disk.
The system doesn’t always wait the full 30 seconds before writing cached journal entries from memory to disk. It writes cached entries to disk based on the maximum number of journal entries that can be written to disk at one time (one disk write).
When your system memory contains the maximum number of journal entries that can be written in one disk write, the system immediately writes all the journal entries in memory to disk. This is the optimal time period for journal entry disk write performance.
If your system memory contains less than the maximum number of cached journal entries that can be written to disk and the CACHEWAIT timer has expired (30 seconds have gone by in the default setup), the system will stop waiting for memory to fill up with journal entries and write the journal entries from memory to disk. It will immediately write these lingering cached journal entries to disk without waiting for a full disk write. This produces the cache sweeper effect Chad was referring to, where cached journal entries can only sit in memory for the time specified in CACHEWAIT before they are automatically written to disk.

Chad also added these thoughts on how journal caching relates to commitment control:

“We also thought your comment on commitment control may have been a bit strong. The purpose of commitment control is not to thwart journal caching, but rather to ensure transaction integrity.”

The comment I made in the previous article was that “Commitment control breaks journal caching by putting your job back into the journal wait state that journal caching is designed to avoid,” which as Chad said may have been too strong and unappreciative of what commitment control does for data integrity. If you want to turn on journal caching while using commitment control, I recommend checking with IBM or your business partner to make sure your system is correctly set up for your needs.

Thanks to Chad Olstad for pointing me toward this additional information on journal caching and commitment.

–Joe

Joe Hertvik is an IBM i subject matter expert (SME) and the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago, featuring multiple IBM i ERP systems. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002. Check out his blog where he features practical information for tech users at joehertvik.com.

Admin Alert: When Journaling Slows Down Your System, And What To Do About It

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot