Hi Dan,
Bit hazy about you deployment. Too many to track!
When there is a persistent database, TDB uses memory mapped files. The
space shows as part of the JVM process (it's a virtual memory mapping
from the file system); it's not heap.
It means a Java process can look huge - 100Gs is possible.
But it's being managed by the OS file system cache. It's paged; real RAM
is being used as a cache. That's why allocating all RAM to the java heap
is a bad idea for TDB. It leaves less space for indexes to be cached.
Solr is using "direct memory" - that's part of the processes RAM but not
part of the heap. It's fixed at startup (-XX:MaxDirectMemorySize).
More RAM can be added to a process via the sbrk system call (linux) -
adds space to the top of the process (it's a linear address space). The
heap is top of RAM so as the heap grows from initial size, the JVM is
sbrk-ing more memory up until the -Xmx limit and the JVM often prefers
to sbrk than to do a full GC. Full GC is expensive because it involves
relocating objects which copying memory.
Returning memory to the OS (to the VM OS, not the host OS) has benefits
if memory usage has unusual spikes, and then subsides to a long term low
level. But if the memory rising and falling regularly, it's overhead.
Andy
BTW -XX:UseContainerSupport defaults to "on" for Java11.
On 30/07/2021 14:49, Dan Pritts wrote:
Andy Seaborne wrote:
Very roughly, Java takes about 0.5G over the heap size so 2.4GB is what to
expect before the runtime triggers a full GC and the full GC will reduce the
heap in uses. The process size will not shrink.
We have experienced some sort of degenerate behavior with fuseki where the
JVM’s non-heap memory gets much larger than normal. (Andy, you may recall that
I sent you heap dumps and other debug information a couple years back.)
We have never figured out the solution, and periodically restart the service to
compensate. We are running what is at this point a quite old version of fuseki, so
some related bug may have been found & fixed. However, I do try to watch the
release notes and didn’t notice anything obviously related.
in general, Andy’s right about the memory usage of Java above & beyond the heap
- but there can be significant exceptions. For example, we use Solr, which uses
java’s NIO facility. NIO uses out-of-heap memory, and we regularly see 4GB
additional usage.
Thanks
danno
