Skip to content

Dev memory config vector indexes #2289

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions modules/ROOT/content-nav.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -213,6 +213,7 @@

* xref:performance/index.adoc[]
** xref:performance/memory-configuration.adoc[]
** xref:performance/vector-index-memory-configuration.adoc[]
** xref:performance/index-configuration.adoc[]
** xref:performance/gc-tuning.adoc[]
** xref:performance/bolt-thread-pool-configuration.adoc[]
Expand Down
1 change: 1 addition & 0 deletions modules/ROOT/pages/performance/index.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ This section describes factors that affect operational performance and how to tu
The following topics are covered:

* xref:performance/memory-configuration.adoc[Memory configuration] -- How to configure memory settings for efficient operations.
* xref:performance/vector-index-memory-configuration.adoc[Vector index memory configuration] -- How to configure memory for vector indexes.
* xref:performance/index-configuration.adoc[Index configuration] -- How to configure indexes.
* xref:performance/gc-tuning.adoc[Garbage collector] -- How to configure the Java Virtual Machine's garbage collector.
* xref:performance/bolt-thread-pool-configuration.adoc[Bolt thread pool configuration] -- How to configure the Bolt thread pool.
Expand Down
3 changes: 3 additions & 0 deletions modules/ROOT/pages/performance/memory-configuration.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,9 @@ It is not possible to explicitly configure the amount of RAM that should be rese
1GB is a good starting point for a server that is dedicated to running Neo4j.
However, there are cases where the amount reserved for the OS is significantly larger than 1GB, such as servers with exceptionally large RAM.
+
If you have a vector index, you need to ensure that the OS has sufficient memory set aside for the vector index to perform optimally, because the vector index is loaded in OS memory and not in Neo4j page cache.
For more information, see xref:performance/vector-index-memory-configuration.adoc[Vector index memory configuration].
+
[NOTE]
====
If you do not leave enough space for the OS, it will start to swap memory to disk, which will heavily affect performance.
Expand Down
163 changes: 163 additions & 0 deletions modules/ROOT/pages/performance/vector-index-memory-configuration.adoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,163 @@
= Vector index memory configuration
:description: How to configure Neo4j vector indexes to enhance performance in search operations.

link:{neo4j-docs-base-uri}/cypher-manual/current/indexes/semantic-indexes/vector-indexes/[Vector indexes] are based on link:https://lucene.apache.org/[Lucene].
Lucene does not use Neo4j page cache memory, it uses OS memory as described in the xref:performance/memory-configuration.adoc[Memory configuration] section.
When you have a vector index, you must ensure that there is sufficient memory for the JVM heap, Neo4j page cache, and the Lucene vector indexes to perform optimally.
If Lucene has insufficient memory, the OS will perform page swapping and read data from disk, which will dramatically degrade the Neo4j vector index search performance.
Tools like IOTOP can assist in understanding disk I/O usage.

== Optimal Neo4j memory configuration for vector indexes

The memory configuration recommendations are _Heap + Neo4j PageCache + .25(Vector Index Size) + Additional OS Managed Memory_.

=== Considerations and caveats

You can reduce the Neo4j page cache if you plan not to return vectors to the user or calling application, as the vectors are not needed and should not be loaded into memory.
For example, the vector storage in a database with a total size of 459 GB is 402 GB.
By setting the page cache to 100 GB, the important part of the graph is still in memory, and the server requirements are reduced.
The ratio of memory to storage will be high, but Neo4j will still be able to maintain its performance.
A 1:4 ratio should perform well.

You must increase the memory if you plan to return vectors to the user or call the application and use them for a refined search.
If you use the vectors for further searching or refining search results, the page cache memory allocation must also be increased.

=== Example calculations

The following examples show how to calculate the memory requirements when vectors are only used for searching and will not be returned to the user or application.

.Disk storage requirements
[cols="h,1,1"]
|===
| Neo4j DB
| 10M
| ~40GB

| Vector Index (single index)
| (1.1 * (4 * 768 + 8 * 16) * 10M)/1048576000
| 33.5GB

| Total DB Size
|
| 73.5GB
|===

.Memory requirements
[cols="h,1,1"]
|===
| Heap
| 10-20GB
| 20GB

| Page Cache
| DB Size * 1.2
| 50GB

| OS Memory for Index
| .4 of the Vector Index
| 12GB

| Total
|
| 82GB
|===

.Aura vector specified cluster memory configurations
[options="header", cols="1,1,1,1,1"]
|===
| Instance Size
| Disk Storage
| Heap
| Page Cache
| Remaining Memory

| 32GB
| 64GB
| 7.58GB
| 9.01GB
| 15.41GB

| 64GB
| 128GB
| 16.17GB
| 17.56GB
| 30.27GB

| 128GB
| 256GB
| 26.90GB
| 49.94GB
| 51.16GB

| 256GB
| 512GB
| 31GB
| 132.34GB
| 92.66GB

| 384GB
| 768GB
| 31GB
| 220.25GB
| 132.75GB

| 512GB
| 1024GB
| 31GB
| 308.55GB
| 172.45GB
|===

.Aura non-vector specified cluster memory configurations
[options="header", cols="1,1,1,1,1"]
|===
| Instance Size
| Disk Storage
| Heap
| Page Cache
| Remaining Memory

| 32GB
| 64GB
| 10.39GB
| 11.13GB
| 10.48GB

| 64GB
| 128GB
| 20.57GB
| 23.43GB
| 20GB

| 128GB
| 256GB
| 29.60GB
| 70.40GB
| 28GB

| 256GB
| 512GB
| 31GB
| 180.20GB
| 44.8GB

| 384GB
| 768GB
| 31GB
| 293.20GB
| 59.8GB

| 512GB
| 1024GB
| 31GB
| 410.5GB
| 70.5GB
|===

== Warming up the vector index

The Neo4j vector index is only loaded into memory when it is accessed.
Ideally, the Lucene vector index is preloaded into OS-managed memory before quering the index.
However, you can also warm up the index by running a few random queries to help the OS load the index into memory.
The number of queries required to warm up the index depends on the size of the index and the amount of memory available.
For a smaller index (up to 1M entries), five queries should be sufficient to load the index into memory.