Architecture - eXist: A NoSQL Database and Application Development Platform - page 86

In any database system, aside from network I/O, disk I/O is always the slowest com‐
ponent. For example, at the time of writing, suppose you want to read 1 MB of data
from disk. It typically takes 32 times as long just to locate the data on the disk as it
does to read it from memory. To then actually read the data from disk takes 80 times
as long as it does to read it from memory. Therefore, it is highly desirable to optimize
any database system to avoid disk I/O as much as possible, and eXist is no exception.
Access to all database files in eXist that make use of paging is performed through spe‐
cific page caches. The job of the caches is to keep frequently accessed data in mem‐
ory, to avoid having to retrieve it from disk. eXist has separate caches for the data and
index sections of its files. The caches in eXist are LRU (Least Recently Used) caches,
so pages are evicted from the caches (under various circumstances) based on the time
they were last accessed. In particular, the caches for the index sections (B+ tree) dis‐
tinguish between pages that contain internal (nonleaf) nodes and leaf nodes. Since
internal nodes are likely to be accessed more frequently, they are assigned a higher
priority and are not evicted from the cache before related leaf nodes.
Caches grow (up to a maximum limit) and shrink automatically as required. If a
cache is thrashing (i.e., pages are frequently replaced), it will request more memory
from the cache manager. Providing the cache manager has memory available, extra
memory will always be granted to a requesting cache. Exactly how and when a cache
grows is specific to each cache implementation. For example, the data section cache
of the persistent on-disk DOM will never grow, because it is very unlikely that the
same page will be frequently accessed over a short, finite duration; therefore, the
cache size is fixed to 256 pages (typically 1 MB when you're using 4 KB pages).
Conversely, the collection cache attempts to calculate the memory required by the
metadata of each collection, and tries to fill itself with the metadata of the hottest col‐
lections. During periods of low database activity, the cache manager may decide to
reclaim space from the caches so that it can quickly be reallocated in the future.
Caches in eXist are configured to use an explicit maximum amount
of memory, which is subtracted from the maximum memory made
available to eXist (the JVM's -Xmx maximum memory setting).
All caches (except the collection cache) share a single caching space
in memory. The size of this caching space is configurable in
$EXIST_HOME/conf.xml via the attribute indicated by the XPath /
exist/db-connection/@cacheSize . The collection cache (for collec‐
tions.dbx ) has its own caching space in memory and may likewise
be configured in the same file at the XPath /exist/db-connection/
@collectionCache .
For information on how to tune eXist's memory and cache settings for your database,
see “Cache Tuning” on page 394 .