This section provides an overview of performance considerations for disk and RAM when running Neo4j.
As with any persistence solution, performance depends a lot on the persistence media used. In general, the faster storage you have, and the more of your data you can fit in RAM, the better performance you will get.
If you have multiple disks or persistence media available it may be a good idea to divide the store files and transaction logs across those disks. Keeping the store files on disks with low seek time can do wonders for read operations. Today a typical mechanical drive has an average seek time of about 5ms. This can cause a query or traversal to be very slow when the amount of RAM assigned to the page cache is too small. A new, good SATA enabled SSD has an average read service time of less than 100 microseconds, meaning those scenarios will execute at least 50 times faster, and modern NVMe drives can service reads in 10 to 50 microseconds. However, this is still hundreds of times slower than accessing RAM.
To avoid hitting disk you need more RAM. On a standard mechanical drive you can handle graphs with a few tens of millions of primitives (nodes, relationships and properties) with 2-3 GBs of RAM. A server with 8-16 GBs of RAM can handle graphs with hundreds of millions of primitives, and a good server with 16-64 GBs can handle billions of primitives. However, if you invest in a good SSD you will be able to handle much larger graphs on less RAM.
Use tools like
vmstat to gather information when your application is running.
If the swap or paging numbers are high, that is a sign that the Lucene indexes don’t quite fit in memory.
In this case, queries that do index lookups will have high latencies.
When Neo4j starts up, its page cache is empty and needs to warm up. The pages, and their graph data contents, are loaded into memory on demand as queries need them. This can take a while, especially for large stores. It is not uncommon to see a long period with many blocks being read from the drive, and high IO wait times. This will show up in the page cache metrics as an initial spike in page faults. The page fault spike is then followed by a gradual decline of page fault activity, as the probability of queries needing a page that is not yet in memory drops.
The Neo4j Enterprise Edition has a feature called active page cache warmup, which shortens the page fault spike and makes the page cache warm up faster. This is done by periodically recording cache profiles of the store files, as the database is running. These profiles contain information about what data is and is not in memory, and are stored in a "profiles" sub-directory of the store directory. When Neo4j is later restarted, it will look for these cache profiles and eagerly load in the same data that was in memory when the profile was created. The profiles are also copied as part of online backup and cluster store-copy, and helps warm up new database instances that join a cluster.
Neo4j flushes its page cache in the background as part of its checkpoint process.
This will show up as a period of elevated write IO activity.
If the database is serving a write-heavy workload, the checkpoint can slow the database down by reducing the IO bandwidth
that is available to query processing.
Running the database on a fast SSD, which can service a lot of random IOs, significantly reduces this problem.
If a fast SSD is not available in your environment, or if it is insufficient, then an artificial IOPS limit can be placed
on the checkpoint process.
dbms.checkpoint.iops.limit restricts the IO bandwidth that the checkpoint process is allowed to use.
Each IO is, in the case of the checkpoint process, an 8 KiB write.
An IOPS limit of 300, for instance, would thus only allow the checkpoint process to write at a rate of roughly 2.5 MiB per
This will, on the other hand, make checkpoints take longer to complete.
A longer time between checkpoints can cause more transaction log data to accumulate, and can lengthen recovery times.
See the transaction logs section for more details on the relationship between checkpoints and log pruning.
The IOPS limit can be changed at runtime, making it possible to tune it until you have the right balance between IO usage and checkpoint time.