IBM i Journal Caching: A Simple Way to Cut Journal Overhead
Journaling is one of those IBM i features that quietly does a lot of work. It underpins recovery, commitment control, object auditing and most software-based replication, including Maxava HA. That reliability comes at a cost, though: every journal entry is normally written synchronously to disk before the application can carry on, and on a busy system that adds up fast. Journal caching, delivered through the HA Journal Performance option, addresses that overhead directly, and it has been free to enable since IBM's 2022 software simplification announcement. Even so, plenty of IBM i shops still have not turned it on. Here is what it does, what the numbers actually look like, and where the trade-offs sit.
What journal caching changes
Without caching, each journal entry is written to the journal receiver as it happens, and the application waits for that write to complete before moving on. The HA Journal Performance option, licensed program 5770-SS1 option 42, introduces journal caching on the local journal. Rather than writing entries one at a time, IBM i holds them in memory and writes them to the receiver as a group once a 128KB bundle has been assembled. Fewer, larger disk writes are considerably more efficient than many small ones, and the application spends less time waiting.
Turning it on is a one-line change: CHGJRN JRN(yourjournal) JRNCACHE(*YES). Option 42 itself needs to be downloaded and installed from IBM's Entitled Software Support site first, since it is a separate product option even though there is no charge for it.
The performance difference
In performance testing run for a recent Maxava whitepaper, a baseline workload with no journal caching took just under an hour to complete. With JRNCACHE(*YES) enabled on the same workload, the test finished in eight minutes. Journal wait time, visible as its own category in the Performance Data Investigator's Waits Overview, was effectively eliminated. CPU utilization on the source system was higher with caching enabled, peaking at close to 60 percent, and disk time was concentrated into two short, intense intervals rather than spread across the whole run. Even so, total disk time for the test was lower than the baseline. Writing larger amounts of data less often is simply more efficient than writing small amounts constantly, and the numbers back that up clearly.
Be aware of delivery mode
Journal caching interacts directly with remote journal delivery mode, and it is worth getting this right. In asynchronous delivery mode, control returns to the application before the journal entry reaches the target system, so caching and async delivery pair well: entries are still sent to the remote journal as a group, and there is no performance penalty on the target side. In synchronous delivery mode, the application already waits for the target to acknowledge each entry, and cached entries are not sent until the bundle is written to disk locally, so combining JRNCACHE(*YES) with *SYNC delivery does not deliver the same benefit.
It is also worth noting that if your application uses commitment control, journal caching will have little or no additional effect, since commitment control already batches journal entries in a similar way.
Any downsides?
The efficiency comes from holding entries in memory briefly before they hit disk, and that introduces a small but real risk. If the source system fails before a cache bundle is written, those entries, potentially the better part of a 128KB block, are lost. If you are replicating to a target system, that target will be missing the same entries. For most files this is an acceptable trade against a meaningful performance gain, but it is worth reviewing which journals carry your most sensitive transactions before enabling caching broadly and deciding deliberately rather than by default.
Consider the network
Because caching sends the same total volume of data to a remote journal, just compressed into a much shorter window, the network connection between source and target needs to absorb sharper spikes rather than a steady trickle. Maxava's testing showed exactly this pattern on the Ethernet Protocol Overview chart, with transmitted kilobytes per second jumping sharply for a brief period rather than staying level across the run. If your DR link is already close to capacity, particularly over WAN or cloud connections, it is worth checking headroom before rolling caching out broadly.
Getting started
If you have not looked at journal caching before, start small. Confirm option 42 is installed, pick an asynchronous remote journal on a non-critical file as a first test, and use Performance Data Investigator to compare the Waits Overview and Ethernet Protocol Overview before and after. The gains are usually visible immediately, and understanding the trade-off on a low-risk journal first makes it much easier to decide where else it makes sense across your environment.
