Hi Kumar,
Artemis and Artemis Console went through _major_ changes between Artemis 2.37.0
and 2.50.0. It doesn’t mean newest version will solve your particular issue,
but if you want debugging and reporting a bug to be more productive, you should
definitely upgrade before that.
--
Best Regards,
Vilius
From: Shiv Kumar Dixit <[email protected]>
Sent: Wednesday, February 25, 2026 6:50 PM
To: [email protected]
Subject: RE: Broker Pod Goes into restart while purging pending via GUI console
operations
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]<mailto:[email protected]>>
Sent: 25 February 2026 12:12 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.
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
