Huge resident size despite small heap

[Bernd Eckenfels]

Hello,

You can also check Direct Memory usage of NIO DirectByteBuffer, I think there is a JMX bean for it.  If the number of thread stacks and the MetaSpace is not an issue, this (and native leak) is the only thing which can account for such large usage. Also you can look at the memory mappings, there you can at least see if it is a single region or multiple, accounting for the memory (/proc/pid/(s)maps).

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: hotspot-gc-use <hotspot-gc-use-retn at openjdk.java.net> im Auftrag von Per Liden <per.liden at oracle.com>
Gesendet: Monday, March 28, 2022 10:29:04 AM
An: Stefan Reich <stefan.reich.maker.of.eye at googlemail.com>; hotspot-gc-use at openjdk.java.net <hotspot-gc-use at openjdk.java.net>
Betreff: Re: Huge resident size despite small heap

As a start, you could enable native memory tracking in the JVM and see
if that tells you anything.

$ java -XX:NativeMemoryTracking=summary ...
$ jcmd <pid> VM.native_memory

If it doesn't, I would look closer at that native library and how it's used.

cheers,
Per

On 3/27/22 23:18, Stefan Reich wrote:
> Oops, correction (sorry for spam) - these options aren't even used in
> the process in question. It's -Xmx2g, and nothing else.
>
> On Sun, 27 Mar 2022 at 23:17, Stefan Reich
> <stefan.reich.maker.of.eye at googlemail.com
> <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
>
>     Quick follow-up: The only GC-related command line options I use are
>
>        -XX:MaxHeapFreeRatio=20 -XX:MinHeapFreeRatio=10
>     -XX:+UseStringDeduplication
>
>     On Sun, 27 Mar 2022 at 23:14, Stefan Reich
>     <stefan.reich.maker.of.eye at googlemail.com
>     <mailto:stefan.reich.maker.of.eye at googlemail.com>> wrote:
>
>         Hi, I am currently running OpenJDK 16 on my server (will upgrade
>         to 17 when I'm sure none of my code is dependent on illegal
>         accesses). OS is Ubuntu 18.
>
>         I am noticing that a long running server process eventually
>         (after a few days) grows enormously in its resident size. Right
>         now it is at 7 GB. Performing a GC doesn't get it any lower.
>
>         The weird part is that the process is run with -Xmx2g, and
>         currently used heap according to java.lang.Runtime is only 400
>         MB after GC, going up to at most 1 GB in operation.
>
>         How do these numbers fit together?
>
>         I've seen the resident size even higher (13+ GB), and at that
>         point I noticed the process getting significantly slower too
>         (web pages taking 1-2 seconds to load instead of near instant).
>
>         At a typical moment in time, no Java threads are running (I
>         monitor this every second).
>
>         An obvious suspect is of course any native library loaded. The
>         only native library in use is, I think, the OSHI library.
>
>         Any ideas why this might be happening?
>
>         Many greetings,
>         Stefan
>
>         --
>         == Gaz.AI <http://Gaz.AI> ==
>
>
>
>     --
>     == Gaz.AI <http://Gaz.AI> ==
>
>
>
> --
> == Gaz.AI <http://Gaz.AI> ==
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20220328/de55dd6b/attachment.htm>