JE uses some background threads to keep your database resources with in preconfigured limits. If they are going to run, the background threads are started once per application per process. That is, if your application opens the same environment multiple times, the background threads will be started just once for that process. See the following list for the default conditions that gate whether an individual thread is run. Note that you can prevent a background thread from running by using the appropriate je.properties parameter, but this is not recommended for production use and those parameters are not described here.
The background threads are:
Cleaner thread.
Responsible for cleaning and deleting unused log files. See The Cleaner Thread for more information.
This thread is run only if the environment is opened for write access.
Compressor thread.
Responsible for cleaning up the internal BTree as database records are deleted. The compressor thread ensures that the BTree does not contain unused nodes. There is no need for you to manage the compressor and so it is not described further in this manual.
This thread is run only if the environment is opened for write access.
Evictor thread.
Removes database records out of the in-memory cache in the event that the cache has reached a predefined maximum size. See The Evictor Thread for more information.
This thread always runs.
Checkpointer thread.
Responsible for running checkpoints on your environment. See The Checkpointer Thread for more information.
This thread is run only if the environment is configured to support transactions.
The cleaner thread is responsible for cleaning, or compacting, your log files for you. Log file cleaning is described in Cleaning the Log Files.
The following two properties may be of interest to you when managing the cleaner thread:
je.cleaner.minUtilization
Identifies the percentage of the log file space that must be used for utilized records. If the percentage of log file space used by utilized records is too low, then the cleaner removes obsolete records until this threshold is reached. Default is 50%.
je.cleaner.expunge
Identifies the cleaner's behavior in the event that it is able to remove a log file. If true, the log files that have been cleaned are deleted from the file system. If false, the log files that have been cleaned are renamed from NNNNNNNN.jdb to NNNNNNNN.del. You are then responsible for deleting the renamed files.
Note that the cleaner thread runs only if the environment is opened for write access.
JE limits the size of its cache based on values set for the environment. Once the size of the cache reaches the defined limit, the evictor thread evicts parts of the cache to free up cache space. Note that any modified records evicted from the cache are written to the backing files on disk. The evictor thread evicts the least used portions of the cache.
To control the amount of memory that your cache can use, use the je.maxMemoryPercent or je.maxMemory properties. For advice on sizing your cache, see Sizing the Cache.
Please see the example.properties file that is available in your JE source distribution for the default value set for this parameter.
Note that this thread always runs.
Automatically runs checkpoints. Checkpoints are described in Checkpoints.
Currently, the only checkpointer property that you may want to manage is je.checkpointer.bytesInterval. This property identifies how much JE's log files can grow before a checkpoint is run. Value is specified in bytes. Decreasing this value causes the checkpointer thread to run checkpoints more frequently. This will improve the time that it takes to run recovery, but it also increases the system resources (notably, I/O) required by JE.