Here's one other entry that is probably interesting:
Improved performance for applications having a very large JE cache
and where
the active data set fits in the cache. Before, in this scenario,
checkpoints
could take a long time to occur. This in turn prevented log cleaning
from
being performed until after the end of the checkpoint. Two changes
were made:
- Cleaner utilization information is now updated during the
checkpoint. The
log cleaner will no longer wait until the end of the checkpoint to
perform
cleaning. Note that although cleaning takes place during the
checkpoint, log files are still not deleted until the end of the checkpoint.
- A new environment configuration parameter --
je.checkpointer.highPriority
-- can be used to reduce the time to perform a checkpoint. If set to
true, the
checkpointer uses more resources in order to complete the checkpoint in a
shorter time interval. Btree latches are held and other threads are
blocked
for a longer period. Log cleaner record migration is performed by
cleaner
threads instead of during checkpoints. A shorter checkpoint is
beneficial
because a shorter recovery period will be required in the event of a
crash.
However, application response time may be longer during the
checkpoint, and
more cleaner threads may be required to maintain the configured je.cleaner.minUtilization.
