From stefan.reich.maker.of.eye at googlemail.com Sun Mar 27 21:14:36 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Sun, 27 Mar 2022 23:14:36 +0200 Subject: Huge resident size despite small heap Message-ID: 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 == -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Sun Mar 27 21:17:13 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Sun, 27 Mar 2022 23:17:13 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: 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> 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 == > -- == Gaz.AI == -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Sun Mar 27 21:18:49 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Sun, 27 Mar 2022 23:18:49 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: 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> 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> 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 == >> > > > -- > == Gaz.AI == > -- == Gaz.AI == -------------- next part -------------- An HTML attachment was scrubbed... URL: From per.liden at oracle.com Mon Mar 28 08:29:04 2022 From: per.liden at oracle.com (Per Liden) Date: Mon, 28 Mar 2022 10:29:04 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: As a start, you could enable native memory tracking in the JVM and see if that tells you anything. $ java -XX:NativeMemoryTracking=summary ... $ jcmd 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 > > 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 > > 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 == > > > > -- > == Gaz.AI == > > > > -- > == Gaz.AI == > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use From thomas.stuefe at gmail.com Mon Mar 28 09:03:30 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 28 Mar 2022 11:03:30 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: Hi Stefan, as Per wrote, try NMT first. NMT got improved a lot in the last JDK versions. JDK18 would actually be the best. More random thoughts: One thing to try is to use `jcmd System.trim_native_heap`. That will trim the glibc C-Heap from internally accumulated overhead. It needs JDK17 though. Another thing to try is to reduce the number of malloc arenas, MALLOC_ARENA_MAX. To reduce malloc contention, glibc works with arenas, and MALLOC_ARENA_MAX depends on the number of processors. These ideas are not necessarily solutions, but steps to exclude that the RSS increase is caused by the glibc. Cheers, Thomas On Sun, Mar 27, 2022 at 11:15 PM Stefan Reich < 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 == > _______________________________________________ > 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: From ecki at zusammenkunft.net Mon Mar 28 09:12:30 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Mon, 28 Mar 2022 09:12:30 +0000 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: 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 im Auftrag von Per Liden Gesendet: Monday, March 28, 2022 10:29:04 AM An: Stefan Reich ; 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 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 > > 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 > > 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 == > > > > -- > == Gaz.AI == > > > > -- > == 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: From stefan.reich.maker.of.eye at googlemail.com Mon Mar 28 09:26:27 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 28 Mar 2022 11:26:27 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: Thanks for your answers, I will investigate! On Mon, 28 Mar 2022 at 11:12, Bernd Eckenfels 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 im Auftrag > von Per Liden > *Gesendet:* Monday, March 28, 2022 10:29:04 AM > *An:* Stefan Reich ; > 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 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 > > > >> 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 > > > >> 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 == > > > > > > > > -- > > == Gaz.AI == > > > > > > > > -- > > == 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 > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- == Gaz.AI == -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Mon Mar 28 09:34:21 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 28 Mar 2022 11:34:21 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: Hi Bernd, Note that DBB usage shows up in NMT too, as "Other" category. Cheers, Thomas On Mon, Mar 28, 2022 at 11:12 AM Bernd Eckenfels 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 im Auftrag > von Per Liden > *Gesendet:* Monday, March 28, 2022 10:29:04 AM > *An:* Stefan Reich ; > 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 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 > > > >> 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 > > > >> 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 == > > > > > > > > -- > > == Gaz.AI == > > > > > > > > -- > > == 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 > _______________________________________________ > 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: From java at elyograg.org Mon Mar 28 14:13:39 2022 From: java at elyograg.org (Shawn Heisey) Date: Mon, 28 Mar 2022 08:13:39 -0600 Subject: Huge resident size despite small heap In-Reply-To: References: Message-ID: <9b70f461-82af-d746-7cc9-583ed1522426@elyograg.org> On 3/27/22 15:14, Stefan Reich wrote: > 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. I've seen this with Java before, specifically with Solr.? In "top" the RES size for the Solr process would get abnormally huge.? But I also saw SHR get large.? Subtracting SHR from RES would yield the expected amount of memory usage. I know it has to be a reporting problem, not a case of Java taking more than it was allowed.? I know this because when I took the entire output from "top" into consideration (including the disk cache) it all added up to a lot more memory than the machine actually had.? But if I viewed actual memory usage as RES minus SHR, it would all add up correctly. I've also seen this on Windows servers. Thanks, Shawn From stefan.reich.maker.of.eye at googlemail.com Mon Mar 28 15:31:14 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 28 Mar 2022 17:31:14 +0200 Subject: Huge resident size despite small heap In-Reply-To: <9b70f461-82af-d746-7cc9-583ed1522426@elyograg.org> References: <9b70f461-82af-d746-7cc9-583ed1522426@elyograg.org> Message-ID: Hi Shawn - interesting, but that's not it... https://botcompany.de/images/1103113 SHR is 63 MB, RES 7440 MB On Mon, 28 Mar 2022 at 17:22, Shawn Heisey wrote: > On 3/27/22 15:14, Stefan Reich wrote: > > 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. > > I've seen this with Java before, specifically with Solr. In "top" the > RES size for the Solr process would get abnormally huge. But I also saw > SHR get large. Subtracting SHR from RES would yield the expected amount > of memory usage. > > I know it has to be a reporting problem, not a case of Java taking more > than it was allowed. I know this because when I took the entire output > from "top" into consideration (including the disk cache) it all added up > to a lot more memory than the machine actually had. But if I viewed > actual memory usage as RES minus SHR, it would all add up correctly. > > I've also seen this on Windows servers. > > Thanks, > Shawn > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- == Gaz.AI == -------------- next part -------------- An HTML attachment was scrubbed... URL: From java at elyograg.org Mon Mar 28 15:51:58 2022 From: java at elyograg.org (Shawn Heisey) Date: Mon, 28 Mar 2022 09:51:58 -0600 Subject: Huge resident size despite small heap In-Reply-To: References: <9b70f461-82af-d746-7cc9-583ed1522426@elyograg.org> Message-ID: <8aab9a41-bf56-0137-9a84-e4c8ce20a9b8@elyograg.org> On 3/28/22 09:31, Stefan Reich wrote: > Hi Shawn - interesting, but that's not it... > https://botcompany.de/images/1103113 That makes me suspect that Java is not being given the memory options you think it is.? Take a look at the output from this command, and share it if you can, substituting the correct PID number if that has changed: ps axww | grep 6344 If the ps on that system doesn't like those options, replace "axww" with "-aef". Thanks, Shawn From stefan.reich.maker.of.eye at googlemail.com Mon Mar 28 16:23:54 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 28 Mar 2022 18:23:54 +0200 Subject: Huge resident size despite small heap In-Reply-To: <8aab9a41-bf56-0137-9a84-e4c8ce20a9b8@elyograg.org> References: <9b70f461-82af-d746-7cc9-583ed1522426@elyograg.org> <8aab9a41-bf56-0137-9a84-e4c8ce20a9b8@elyograg.org> Message-ID: Yeah I gotcha... here it is: root at c8:~# ps -aef|grep 6344 root 6344 1 24 Mar22 ? 1-10:46:31 java --illegal-access=permit -Xmx2g --add-opens java.base/jdk.internal.loader=ALL-UNNAMED --add-opens java.base/jdk.internal.module=ALL-UNNAMED --add-opens java.base/jdk.internal.ref=ALL-UNNAMED --add-opens java.base/java.lang.module=ALL-UNNAMED --add-opens java.base/jdk.internal.reflect=ALL-UNNAMED -jar /root/.javax/x30.jar 1013896 On Mon, 28 Mar 2022 at 17:52, Shawn Heisey wrote: > On 3/28/22 09:31, Stefan Reich wrote: > > Hi Shawn - interesting, but that's not it... > > https://botcompany.de/images/1103113 > > That makes me suspect that Java is not being given the memory options > you think it is. Take a look at the output from this command, and share > it if you can, substituting the correct PID number if that has changed: > > ps axww | grep 6344 > > If the ps on that system doesn't like those options, replace "axww" with > "-aef". > > Thanks, > Shawn > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use at openjdk.java.net > https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use > -- == Gaz.AI == -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.reich.maker.of.eye at googlemail.com Wed Mar 30 16:59:51 2022 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Wed, 30 Mar 2022 18:59:51 +0200 Subject: Huge resident size despite small heap In-Reply-To: References: <9b70f461-82af-d746-7cc9-583ed1522426@elyograg.org> <8aab9a41-bf56-0137-9a84-e4c8ce20a9b8@elyograg.org> Message-ID: Process got to 9GB, yet various diagnostics still unremarkable: MemoryMXBean.getHeapMemoryUsage() showing 1.5 GB committed MemoryMXBean.getNonHeapMemoryUsage() showing 350 MB committed Memory pools also looking healthy: https://botcompany.de/images/1103117 (Big Eden space though. Is that normal?) I did find the courage to upgrade to JDK 18. So far the ship is afloat. Have enabled NMT too. Patient will be monitored. Thanks On Mon, 28 Mar 2022 at 18:23, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Yeah I gotcha... here it is: > > root at c8:~# ps -aef|grep 6344 > root 6344 1 24 Mar22 ? 1-10:46:31 java > --illegal-access=permit -Xmx2g --add-opens > java.base/jdk.internal.loader=ALL-UNNAMED --add-opens > java.base/jdk.internal.module=ALL-UNNAMED --add-opens > java.base/jdk.internal.ref=ALL-UNNAMED --add-opens > java.base/java.lang.module=ALL-UNNAMED --add-opens > java.base/jdk.internal.reflect=ALL-UNNAMED -jar /root/.javax/x30.jar 1013896 > > On Mon, 28 Mar 2022 at 17:52, Shawn Heisey wrote: > >> On 3/28/22 09:31, Stefan Reich wrote: >> > Hi Shawn - interesting, but that's not it... >> > https://botcompany.de/images/1103113 >> >> That makes me suspect that Java is not being given the memory options >> you think it is. Take a look at the output from this command, and share >> it if you can, substituting the correct PID number if that has changed: >> >> ps axww | grep 6344 >> >> If the ps on that system doesn't like those options, replace "axww" with >> "-aef". >> >> Thanks, >> Shawn >> >> _______________________________________________ >> hotspot-gc-use mailing list >> hotspot-gc-use at openjdk.java.net >> https://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use >> > > > -- > == Gaz.AI == > -- == Gaz.AI == -------------- next part -------------- An HTML attachment was scrubbed... URL: