Real-world example of Java/OrientDB memory configuration for a dedicated 32G or 64G Linux server

[Eric24]

There is little documentation (but Google searches and ChatGPT research both turn up a lot of conflicting information) on Java/OrientDB memory configuration parameters. I'm hoping to get some feedback from real-world experience on this. The relevant settings I've "derived" for a 32G and a 64G server are shown below. I welcome any comments, questions, or feedback, including suggestions of other settings that should be considered.

32G Server
ORIENTDB_OPTS_MEMORY="-Xms6g -Xmx6g -Xss512k"
-XX:MaxDirectMemorySize=18g
ORIENTDB_SETTINGS="-Dstorage.diskCache.bufferSize=15360"

64G Server
ORIENTDB_OPTS_MEMORY="-Xms8g -Xmx8g -Xss512k"
-XX:MaxDirectMemorySize=42g
ORIENTDB_SETTINGS="-Dstorage.diskCache.bufferSize=36864"

Notes

• The value of MaxDirectMemorySize mentioned in the docs is 512g, but I've experienced OOM conditions that appear to be related to this. I found several online mentions of setting this value to 10-20% more than the diskCache.
• Both of these are designed to leave plenty of room for the OS and Java.
• These are assuming dedicated OrientDB servers running on Linux.
• There is some discussion that the heap size may not need to be as large as these examples, but I really couldn't find much detail.
• Same with the stack size (and some recommendations are as small as 256k).

[chadjv]

I'm running OrientDB in a docker container (orientdb:3.2.38) on a VM with 4CPU 32G of memory, wondering if there are any suggestions for this configuration?

[timw]

We're running 32GB production instances with the following config:

• Java heap 3GB
• Disk cache 16GiB

We pre-size Java heap (-Xmx and -Xms), and pre-touch (-XX:+AlwaysPreTouch) and pre-allocate (-Dmemory.directMemory.preallocate=true) direct memory to avoid surprises, but don't limit direct memory allocation at the JVM level.

This is quite a conservative sizing intentionally, and we're getting around nowish to instrumenting disk cache and direct memory allocation so we can track them in our metrics and push them a bit more.
This has been pretty reliable wrt OOM killer issues and overall performance running under significant transaction loads.

Aside from the usual OOM caveats (e.g. the exact JVM and Linux overheads are somewhat unknowable, we have swap configured at low priority just in case Linux decides to get a bit over-eager on the OOM killer, and we're protecting the OrientDB processes from being OOM killer victims), there are some OrientDB specific issues to be careful of, specifically that the write cache is per-database, but it's sized as a proportion of the (server scoped) disk cache configuration.

e.g. 1000MB disk cache at 25% write cache = 750GB of read cache for the server, but 250MB write cache per DB, so if you put 100 DBs on the server, the max write cache size can be more than you intended or can handle.
We operate with a single DB in most production cases, so can ignore that, but it's a gotcha to be careful of.