From robert.bissett at enterprisedb.com  Thu Sep 28 18:57:29 2023
From: robert.bissett at enterprisedb.com (Bobby Bissett)
Date: Thu, 28 Sep 2023 14:57:29 -0400
Subject: question about Java and VIRT(ual) memory
Message-ID: <CA+f84vXhMFxDjTPRDgv=-L0vr2dXFpyCMfGi5jtr5OpEWOAdrA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-use/attachments/20230928/f11e2dbe/attachment.htm>

From stefan.johansson at oracle.com  Fri Sep 29 09:06:18 2023
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Fri, 29 Sep 2023 11:06:18 +0200
Subject: question about Java and VIRT(ual) memory
In-Reply-To: <CA+f84vXhMFxDjTPRDgv=-L0vr2dXFpyCMfGi5jtr5OpEWOAdrA@mail.gmail.com>
References: <CA+f84vXhMFxDjTPRDgv=-L0vr2dXFpyCMfGi5jtr5OpEWOAdrA@mail.gmail.com>
Message-ID: <916a74af-aec4-89ba-50b6-90b3e2871de3@oracle.com>

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
> https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use