question about Java and VIRT(ual) memory

Bobby Bissett robert.bissett at enterprisedb.com
Mon Oct 2 15:15:01 UTC 2023


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

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.)

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

Thank you again for the help,
Bobby

On Fri, Sep 29, 2023 at 5:06 AM Stefan Johansson <
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
> > https://mail.openjdk.org/mailman/listinfo/hotspot-gc-use
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-use/attachments/20231002/c0143aef/attachment.htm>


More information about the hotspot-gc-use mailing list