Thanks for your answers, I will investigate! On Mon, 28 Mar 2022 at 11:12, Bernd Eckenfels <e...@zusammenkunft.net> wrote:
> 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-r...@openjdk.java.net> im Auftrag > von Per Liden <per.li...@oracle.com> > *Gesendet:* Monday, March 28, 2022 10:29:04 AM > *An:* Stefan Reich <stefan.reich.maker.of....@googlemail.com>; > hotspot-gc-use@openjdk.java.net <hotspot-gc-use@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....@googlemail.com > > <mailto:stefan.reich.maker.of....@googlemail.com > <stefan.reich.maker.of....@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....@googlemail.com > > <mailto:stefan.reich.maker.of....@googlemail.com > <stefan.reich.maker.of....@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@openjdk.java.net > > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use@openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use@openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- == Gaz.AI ==
_______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
