On 30/07/2021 23:00, Dan Pritts wrote:
On 30 Jul 2021, at 16:18, Andy Seaborne wrote:
Hi Dan,
Bit hazy about you deployment. Too many to track!
I’m going to have to talk to your supervisor about this. :)
What is this "supervisor" of which you speak?
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.
This isn’t what we have run into - the process’s RSS goes through the roof,
much bigger than the heap. Unfortunately I can’t reproduce it easily, only in
production.
Quote possible - RSS is all process resident memory which includes
memory mapped areas that are currently in the file system cache as
decided by the OS.
https://www.kernel.org/doc/Documentation/filesystems/proc.txt
about /proc/PID/status
Table 1-2
VmRSS size of memory portions. It contains the three
following parts (VmRSS = RssAnon + RssFile + RssShmem)
RssAnon size of resident anonymous memory
RssFile size of resident file mappings
RssShmem size of resident shmem memory (includes SysV shm,
mapping of tmpfs and shared anonymous mappings)
Andy
