Page Cache Size vs Working Set on Neo4j Low-Traffic Instances

Answer

There is no published, version‑specific minimum value for dbms.pagecache_size that guarantees an acceptable hit ratio on Neo4j 5.x. The required size depends entirely on the portion of the working set that must reside in the off‑heap page cache for your read‑only workload.

Likely Explanation vs. Confirmed Facts

Confirmed facts (from Neo4j 5.x documentation and observed behavior)

• The page cache is allocated at startup and stays static; there is no documented runtime auto‑tuner that overrides a manually set size.
• dbms.tx_log.rotation_size controls transaction log rotation and is largely independent of the page‑cache setting; on sparse‑write workloads log rotation is driven by write volume, not by cache size.
• If the page cache is smaller than the working set, page faults increase, which can lead to additional disk reads. Whether those reads appear as random I/O depends on access locality, OS page‑cache behavior, and read‑ahead, not solely on the cache‑size threshold.

Likely explanation (based on typical Neo4j behavior)

For a predominantly read‑only, low‑traffic instance, the hit ratio improves as more of the hot working set (nodes, relationships, properties, and frequently accessed index pages) fits in the page cache. When the cache holds the entire hot set, additional cache yields diminishing returns; when it is smaller, each miss forces a page read from disk, raising latency.

Steps to Size the Cache for Your Instance

1. Estimate the size of the hot working set: sum the sizes of neostore.nodestore.db, neostore.relationshipstore.db, neostore.propertystore.db, and the index files that are actively queried, then add a modest headroom (≈10‑20 %) for growth.
2. Set dbms.pagecache_size in neo4j.conf to at least that estimated size (e.g., dbms.pagecache_size=2G).
3. Restart Neo4j to apply the change.
4. Run a representative read‑only workload and monitor the metrics dbms.page_cache.hits and dbms.page_cache.misses (available via :metrics or JMX). Compute the hit ratio = hits / (hits + misss).
5. If the hit ratio meets your latency target, the current size is sufficient. If not, increase the cache incrementally and repeat the measurement.

Interaction with dbms.tx_log.rotation_size

On sparse‑write workloads the transaction log rotates primarily when the configured dbms.tx_log.rotation_size is reached by write activity. Page‑cache size does not affect when the log rotates; it only influences how often dirty pages are flushed during checkpoints. Thus, reducing the page cache will not directly change log‑rotation frequency, though overall disk I/O may rise due to more page reads.

Missing Diagnostic Detail

To give a numeric recommendation, we need the current working‑set size (or the observed page‑cache hit ratio under load). Please provide either the estimated size of your hot data set or the measured hit ratio with the existing cache setting.