> The "problem" is that I have the instance consuming 1000mb of memory while I have about 300 messages waiting to be consumed...
It's not clear to me if there is an actual increase in heap memory being consumed (which might indicate a real memory leak) or if the broker is simply over-reporting address memory usage (which indicates a simpler accounting error). Do you have any insight into which of these is happening? What exact metrics are you looking at via the web console and via Zabbix? At this point I'd say you should work on a minimal reproducer. Once that's in hand the use-case and operating environment will be clear. Justin On Wed, Sep 10, 2025 at 3:22 AM Gašper Čefarin <[email protected]> wrote: > The "problem" is that I have the instance consuming 1000mb of memory while > I have about 300 messages waiting to be consumed, and the biggest ones are > around 30kb in size. > > > I was inspecting via web console. I still haven't restarted the broker, > the address memory size is up to 1000MB now (according to the web console, > and zabbix monitoring.) Persistent sizes for queues are around 300kb max > according to zabbix. > > > > I did restart the broker after the changes. The journal-buffer.size is at > default - I don't have it in my settings. > > This is a "test" instance and i'm just testing different configurations - > the idea was to keep the majority of messages in memory - and some of the > messages that go through our broker are larger than 100kb. I would expect > the memory to go up if the messages are still waiting in the queues - but > vast majority of them are consumed right away (the ones that aren't are > usually somewhere in a dead letter queue, or a low-traffic queue ...) > > > I'm not sure how to reproduce, but I can try. I didn't want to restart the > broker in case there's any additional info I can get while the instance is > still running. > > There's one more setting that I have enabled even before > minLargeMessageSize, not sure when. Maybe this is the culprit and I didn't > notice increased mem usage before. > > > > <!-- Uncomment the following if you want to use the Standard > LoggingActiveMQServerPlugin pluging to log in events --> > <broker-plugins> > <broker-plugin > class-name="org.apache.activemq.artemis.core.server.plugin.impl.LoggingActiveMQServerPlugin"> > <property key="LOG_ALL_EVENTS" value="true"/> > <property key="LOG_CONNECTION_EVENTS" value="true"/> > <property key="LOG_SESSION_EVENTS" value="true"/> > <property key="LOG_CONSUMER_EVENTS" value="true"/> > <property key="LOG_DELIVERING_EVENTS" value="true"/> > <property key="LOG_SENDING_EVENTS" value="true"/> > <property key="LOG_INTERNAL_EVENTS" value="true"/> > </broker-plugin> > </broker-plugins> > > If you think I can get more data from the running instance, i'll wait, if > not I can restart and try to reproduce. I also configured > HeapDumpOnOutOfMemoryError. > > > > > > ________________________________ > From: Justin Bertram <[email protected]> > Sent: 09 September 2025 22:52 > To: [email protected] > Subject: Re: Large address size for address with no messages in queues > > > To sporočilo izvira izven naše organizacije. Bodite pozorni pri vsebini in > odpiranju povezav ali prilog. > > > > > When you say "the address consumes ~400MB of memory" are you inspecting > this from the web console or some other way? > > Did you restart the broker after making your configuration changes? Did you > happen to adjust the journal-buffer-size? > > Was there a specific reason you increased the minLargeMessageSize? That > could certainly lead to much higher memory utilization. > > Do you have a way to reproduce the issue? > > At this point I'm not sure what the "problem" is or if there really is a > problem. > > > Justin > > On Fri, Sep 5, 2025 at 7:53 AM Gašper Čefarin <[email protected] > > > wrote: > > > Hi, > > i'm using activemq artemis v2.41.0 - > > > > I have an address that has 1 empty (no messages) queue. Even so, the > > address consumes ~400MB of memory (queue1). > > > > The second largest address consumes around 21MB of memory. It also only > > has 1, currently empty queue (queue2). > > > > These 2 queues have the highest "messages added/acked" count: 646640 and > > 648931 respectively (notice that address with less msgs has bigger > address > > size). > > > > If at all important: all of the messages received in queue1 should go to > > queue2 (using camel routes and a couple of custom processors - which > should > > leave the message body unchanged) > > > > So far, ive only noticed address memory rising if there were queues > > waiting to be acknowledged. What's going on - is this a possible memory > > leak? Do you need any more info? > > > > Thanks > > > > > > >
