Hello Clebert, We tried <max-size-bytes>20MB</max-size-bytes> for all addresses (covered via #) and did not change in global-max-size but purge via Operations still resulted in broker container restart. Given we are on 2.37.0 version of broker, we may need to upgrade to higher version as you suggested to see if these changes work or not.
Is there any more config we can try in 2.37.0 or upgrade is the only possibility? Best Regards Shiv From: Clebert Suconic <[email protected]> Sent: 25 February 2026 12:12 AM To: [email protected] Subject: Re: Broker Pod Goes into restart while purging pending via GUI console operations Unverified Sender: The sender of this email has not been verified. Review the content of the message carefully and verify the identity of the sender before acting on this email: replying, opening attachments or clicking links. make <max-size-bytes>20MB</max-size-bytes> <max-read is probably already 2X pagebytes... so it should be fine as is... you can keep global-max-size the way it is... but don't rely on it.. as the broker could be already pegged in memory for other destinations... Also... use this on the latest release. This has been a subject for many changes. Since you are on Kubernetes.. perhaps you can also use broker properties to enable your configurations... look at ./artemis properties to check how the broker would export your XML on a standalone.. and use those. On Tue, Feb 24, 2026 at 10:47 AM Shiv Kumar Dixit <[email protected]<mailto:[email protected]>> wrote: Hello Clebert, Thanks for input. So, we have an address settings section for # and it uses <max-size-bytes>-1</max-size-bytes> currently. I should change it to <max-size-bytes>20000000</max-size-bytes> which is 20 MB? max read of 10MB --> shall I change max-read-page-bytes to 10 MB which is usually 20 MB (2 * default page-size-bytes)? Or you referring any other param? If max-read-page-bytes should be less than max-size-bytes always? With above settings, do we need to reduce/remove <global-max-size> or keep same as current? Best Regards Shiv From: Clebert Suconic <[email protected]<mailto:[email protected]>> Sent: 24 February 2026 07:16 PM To: [email protected]<mailto:[email protected]> Subject: Re: Broker Pod Goes into restart while purging pending via GUI console operations Unverified Sender: The sender of this email has not been verified. Review the content of the message carefully and verify the identity of the sender before acting on this email: replying, opening attachments or clicking links. I would try 2.52. Especially if you want your paging parameters to help. In special have max size per destination. Don’t just use global max size. I suggest 10MB. Or 20Mb. Witj a max read of 10MB Clebert Suconic On Tue, Feb 24, 2026 at 3:57 AM Shiv Kumar Dixit <[email protected]<mailto:[email protected]>> wrote: Hi Justin, We are using Artemis version 2.37.0. 1. Earlier the pod was running without any direct memory settings, and we had defined only min/max heap of 6 GB and global max size of 1200M. 2. Now we enabled direct memory also. So min/max heap is 60% of container, direct memory is 25% of container and rest is left for other native memory usage. Global max size is slightly reduced to 1000 MB from 1200 MB. 3. When we purge via Operations, it is still restarting the pod. If we need to collect any other data? Or tweak other settings related to paging etc.? Best Regards Shiv -----Original Message----- From: Shiv Kumar Dixit Sent: 29 January 2026 01:13 PM To: [email protected]<mailto:[email protected]> Subject: RE: Broker Pod Goes into restart while purging pending via GUI console operations Hello Justin, When we checked the K8s event related to broker pod, it says lastReason=OOMKilled and lastExitCode=137. Best Regards Shiv -----Original Message----- From: Justin Bertram <[email protected]<mailto:[email protected]>> Sent: 24 January 2026 12:37 AM To: [email protected]<mailto:[email protected]> Subject: Re: Broker Pod Goes into restart while purging pending via GUI console operations Unverified Sender: The sender of this email has not been verified. Review the content of the message carefully and verify the identity of the sender before acting on this email: replying, opening attachments or clicking links. Is there any indication of what actually caused the container to be restarted? Are you sure it's related to memory? Justin Justin On Fri, Jan 23, 2026 at 6:51 AM Shiv Kumar Dixit <[email protected]<mailto:[email protected]>> wrote: > > We have an Artemis broker setup running as stateful set with 2 replicas in > K8s. Each replica runs with 6000 MB of heap and 9000 MB of container memory > limit. We have some 300K pending messages on a given address and total > persistent size of it is 1.5 GB on ss-0. Due to some unforeseen issue, we > need to purge these messages. Whenever we try to purge the messages using > broker GUI via operations with a flush limit of 10 or 100 or 1000, ss-0 > container gets restarted. While browsing and purging works fine but it has > limited utility as we can't delete 300k messages that way. But using > operations to purge is making ss-0 restart. > > > > We have captured following stat from ss-0 pod before starting purge via > operations. Any suggestion to fix this issue? Is it a known issue? If we need > to review or tweak any memory setting? > > > > Memory utilization from broker GUI JMX --> java.lang --> Memory > > Heap memory usage { "init": 6291456000, "committed": 6291456000, "max": > 6291456000, "used": 4304010768 } > > Non heap memory usage { "init": 7667712, "committed": 134938624, > "max": 1224736768, "used": 130441792 } > > Object name java.lang:type=Memory > > > > Direct memory utilization from broker GUI JMX --> java.nio --> > BufferPool > > Count Memory used Name Total capacity Object name > > 0 0 mapped - 'non-volatile memory' 0 > java.nio:name=mapped - 'non-volatile memory',type=BufferPool > > 163 46903209 direct 46903208 > java.nio:name=direct,type=BufferPool > > 26 274632 mapped 274632 > java.nio:name=mapped,type=BufferPool > > > > Container memory capture via k8s top pod command > > > kubectl -n xxx top pod xxxx-ss-0 --containers > > POD NAME CPU(cores) MEMORY(bytes) > > xxxx-ss-0 abcd 2998m 8322Mi > > > > Native memory summary of broker pod > > > kubectl -n xxx exec xxxx-ss-0 -- jcmd 1 VM.native_memory summary > > Native Memory Tracking: > > (Omitting categories weighting less than 1KB) > > Total: reserved=7354797KB, committed=6646793KB > > malloc: 99469KB #456441 > > mmap: reserved=7255328KB, committed=6547324KB > > - Java Heap (reserved=6144000KB, committed=6144000KB) > > (mmap: reserved=6144000KB, > committed=6144000KB) > > - Class (reserved=427709KB, committed=9213KB) > > (classes #12081) > > ( instance classes #11254, array classes > #827) > > (malloc=1725KB #39470) (at peak) > > (mmap: reserved=425984KB, > committed=7488KB) > > ( Metadata: ) > > ( reserved=65536KB, committed=59648KB) > > ( used=59166KB) > > ( waste=482KB =0.81%) > > ( Class space:) > > ( reserved=425984KB, committed=7488KB) > > ( used=7092KB) > > ( waste=396KB =5.29%) > > - Thread (reserved=95220KB, committed=18452KB) > > (thread #172) > > (stack: reserved=94724KB, > committed=17956KB) > > (malloc=298KB #1032) (peak=319KB #1075) > > (arena=198KB #340) (peak=757KB #256) > > - Code (reserved=251264KB, committed=48728KB) > > (malloc=3576KB #16397) (peak=3576KB > #16398) > > (mmap: reserved=247688KB, > committed=45152KB) > > - GC (reserved=282161KB, committed=282161KB) > > (malloc=21193KB #31118) (peak=22768KB > #31692) > > (mmap: reserved=260968KB, > committed=260968KB) > > - Compiler (reserved=1470KB, committed=1470KB) > > (malloc=1306KB #1820) (peak=1321KB #1814) > > (arena=165KB #5) (peak=45072KB #14) > > - Internal (reserved=1059KB, committed=1059KB) > > (malloc=1023KB #23952) (at peak) > > (mmap: reserved=36KB, committed=36KB) > > - Other (reserved=44711KB, committed=44711KB) > > (malloc=44711KB #204) (peak=45370KB #195) > > - Symbol (reserved=12165KB, committed=12165KB) > > (malloc=10175KB #299383) (peak=10199KB > #299791) > > (arena=1990KB #1) (at peak) > > - Native Memory Tracking (reserved=7234KB, committed=7234KB) > > (malloc=102KB #1764) (peak=103KB #1769) > > (tracking overhead=7132KB) > > - Shared class space (reserved=16384KB, committed=12068KB) > > (mmap: reserved=16384KB, > committed=12068KB) > > - Arena Chunk (reserved=179KB, committed=179KB) > > (malloc=179KB #411) (peak=47415KB #1421) > > - Module (reserved=275KB, committed=275KB) > > (malloc=275KB #1894) (at peak) > > - Safepoint (reserved=8KB, committed=8KB) > > (mmap: reserved=8KB, committed=8KB) > > - Synchronization (reserved=167KB, committed=167KB) > > (malloc=167KB #1578) (peak=171KB #1588) > > - Serviceability (reserved=1KB, committed=1KB) > > (malloc=1KB #6) (at peak) > > - Metaspace (reserved=65911KB, committed=60023KB) > > (malloc=375KB #355) (at peak) > > (mmap: reserved=65536KB, > committed=59648KB) > > - String Deduplication (reserved=4381KB, committed=4381KB) > > (malloc=4381KB #34592) (peak=6551KB > #38671) > > - Object Monitors (reserved=497KB, committed=497KB) > > (malloc=497KB #2448) (peak=572KB #2814) > > > > Thanks > > Shiv --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected]<mailto:[email protected]> For additional commands, e-mail: [email protected]<mailto:[email protected]> -- Clebert Suconic
