[External] : Re: question about Java and VIRT(ual) memory

Tue Oct 3 07:35:07 UTC 2023

Hi Bobby,

See comments below.

On 2023-10-02 17:15, Bobby Bissett wrote:
> Hi Stefan,
> 
> Thank you for all of this information. FWIW, they're using the 
> overcommit_memory setting because of this:
> https://www.postgresql.org/docs/current/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT <https://urldefense.com/v3/__https://www.postgresql.org/docs/current/kernel-resources.html*LINUX-MEMORY-OVERCOMMIT__;Iw!!ACWV5N9M2RV99hQ!Nvs7kJfYbeEIfpUxTeWtuIYBsHv5TLTH9qXE2TjbGAmcyv0TSebvRzaHdah5wsznwKpsktOkiLKRFpwTSTyaKtnMSKv1xkwHcnY$>
> 
I see, kind of guessed it was something like this. So I assume they will 
keep this setting and then my recommendations from the last mail stand. 
Trying to limit some of the Java sub-systems should help their situation.

> Can you tell me how to know which GC is being used? They're on JDK 1.8 
> now and need to upgrade; I'm suggesting 17 just because I use it, but am 
> open to anything. Anyway, they would install with 'dnf install 
> java-17-openjdk' without any other setup, so I assume would use whatever 
> the default is. (The only startup param we've been running with already 
> is the -Xmx128m one.)
> 

If they don't set a GC on the command-line the default is Parallel GC, 
but depending on the system Serial GC could also be selected if there is 
few cores. But the GC is likely not the problem. The GC with the lowest 
memory overhead is Serial (-XX:+UseSerialGC) and it should be able to 
handle a 128m heap without problems. Still, I would only change this if 
your problems are still present after changing the other options.

You can use a command called 'jmap' to see which GC is used and also 
some of the sizing used by the JVM, run it like this:
jmap -heap <pid>

To see the pid of your process you can simply run:
jcmd

It will list all your Java process on the system.

When it comes to upgrading, JDK 17 was the latest LTS until a few weeks 
back, so it is a stable release. JDK 21 was just released, so that would 
be a valid choice as well. With those two releases G1 GC is the default 
and as mentioned it uses slightly more memory in older releases. In JDK 
21 G1 and Parallel have more or less the same usage. From a memory usage 
point of view upgrading won't have a big effect, but I still encourage 
them to upgrade.

> When I hear back about what happened with the other settings you have 
> suggested I'll respond again here.
> 

Sounds good,
Stefan

> Thank you again for the help,
> Bobby
> 
> On Fri, Sep 29, 2023 at 5:06 AM Stefan Johansson 
> <stefan.johansson at oracle.com <mailto:stefan.johansson at oracle.com>> wrote:
> 
>     Hi Bobby,
> 
>     Generally I would not recommend running with "overcommit_memory=2", so
>     if they can change that it would likely solve their issues. In the JVM
>     many memory reservations (mmap) are using MAP_NORESERVE and this
>     flag is
>     ignored when overcommit_memory is 2. So most reservations will not only
>     reserve virtual address space but also make sure it has backing.
> 
>     With this in mind reducing some default values might help. The
>     compressed class space for example is 1G by default, and just running a
>     "java -version" will reserve that space (and in your case back it up),
>     so setting "-XX:CompressedClassSpaceSize=128m" might make sense.
> 
>     Another flag that could help is "-XX:ReservedCodeCacheSize", but the
>     default size of that is platform depending. On my system it is 240m,
>     and
>     could be reduced a bit for smaller apps. Keep in mind that reducing
>     those defaults, can come with other problems if the application needs
>     space in those areas.
> 
>     Without more information, it is hard to give really good advice. If you
>     can run with native memory tracking turned on we can see what the
>     different sub-systems in the JVM use. Enable it like this:
>     -XX:NativeMemoryTracking=summary -XX:+UnlockDiagnosticVMOptions
>     -XX:+PrintNMTStatistics
> 
>     The print-flag will make the JVM print a summary upon exit. It is also
>     possible to trigger this output using jcmd:
>     jcmd <pid> VM.native_memory
> 
>     It would also be interesting to know which GC you use, G1 and CMS will
>     use more memory compared to Parallel GC for example.
> 
>     Hope this helps,
>     StefanJ
> 
> 
>     On 2023-09-28 20:57, Bobby Bissett wrote:
>      > Hi,
>      >
>      > I tried this question in another mailing list (I didn't know
>     where it
>      > belongs) and someone suggested I try here. If there's another
>     list that
>      > would be better suited, please let me know.
>      >
>      > A customer is running a Java application of ours that runs
>     with -Xmx128m
>      > -- there are no problems specifically with the heap. But the
>     process is
>      > using over 4 gig of VIRT(ual) memory according to 'top'. I didn't
>     think
>      > that was generally an issue, but they are running with
>      > "overcommit_memory=2" on this linux system, and that 4 gig of
>     memory is
>      > hurting things. Is there a jvm parameter to help with this?
>      >
>      > FWIW, they're running openjdk 1.8. They need to upgrade to something
>      > newer; if there's any particular version that might help with the
>      > virtual memory it would be nice to know.
>      >
>      > Thank you,
>      > Bobby Bissett
>      >
>      >
>      > _______________________________________________
>      > hotspot-gc-use mailing list
>      > hotspot-gc-use at openjdk.org <mailto:hotspot-gc-use at openjdk.org>
>      > https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use
>     <https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use>
> 