AMQ performance issue (32gb)

[Shawn Rojo <sh...@comcast.net>]

Good afternoon,

Trying to overcome some performance issues I am experiencing on my lab and hoping this distro can assist. Running version 7.0. My overall config is a VM with 32GB of memory and 8 cores. I have my java -Xmx  set to use 24GB.

With a fairly out of the box config, we could run for about an hour before amq ran out of memory and started to hang.
I then went into the config and setup some defaults for all of our queues such as:

broker.xml
<persistence-enabled>false</persistence-enabled>true
<paging-directory>data/paging</paging-directory>

<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQ</expiry>
<expiry-delay>1000000</expiry>
<send-to-dla-on-no-route>false</send-to-dla-on-no-route>
<max-size-bytes>-1</max-size-bytes>
<page-size-bytes>10000000</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
</address-settings>


In my head, this would cause all messages on all queues to become Expired after 100 seconds. This would then go to the ExpiryQ. At this point the Expiry reaper thread would clean them up thus freeing up memory. 

This doesn't seem to be the case as it is still using all of the memory within about an hour. Am I missing a specific option to help with cleanup of expired messages to not consume all of the memory? Or am I doing something incorrectly? Thanks. 

Also - Would paging be a benefit for this? I have it disabled I believe via the "persistence-enabled" false flag I believe. 

RE: AMQ performance issue (32gb)

["Dondorp, Erwin" <er...@cgi.com.INVALID>]

Shawn,

>    <expiry-delay>1000000</expiry>
That is 1000 seconds (not 100)

> At this point the Expiry reaper thread would clean them up thus freeing up memory.
The reaper has moved the messages from the original queue to the expiry-queue.
Without further measures, the messages will remain on the ExpiryQueue forever.
This is because expiry from the ExpiryQueue would place the messages again on the ExpiryQueue (and is thus a NOP).

You may want to place a consumer there.

Or you can force expiry-with-deletion from the ExpiryQueue itself by using an extra address-setting:
         <address-setting match="ExpiryQueue">
            <expiry-address></expiry-address>
            <min-expiry-delay>60000</min-expiry-delay>
            <max-expiry-delay>60000</max-expiry-delay>
            ...
When expiry-address is empty, the message is expired by just deleting it.
To give it a fixed time-period on the expiry queue, as needed for inspection, set both min-expiry-delay and max-expiry-delay.

e.

-----Oorspronkelijk bericht-----
Van: Shawn Rojo <sh...@comcast.net> 
Verzonden: vrijdag 22 juli 2022 01:03
Aan: users@activemq.apache.org
Onderwerp: AMQ performance issue (32gb)


EXTERNAL SENDER:   Do not click any links or open any attachments unless you trust the sender and know the content is safe.
EXPÉDITEUR EXTERNE:    Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe à moins qu’ils ne proviennent d’un expéditeur fiable, ou que vous ayez l'assurance que le contenu provient d'une source sûre.

Good afternoon,

Trying to overcome some performance issues I am experiencing on my lab and hoping this distro can assist. Running version 7.0. My overall config is a VM with 32GB of memory and 8 cores. I have my java -Xmx  set to use 24GB.

With a fairly out of the box config, we could run for about an hour before amq ran out of memory and started to hang.
I then went into the config and setup some defaults for all of our queues such as:

broker.xml
<persistence-enabled>false</persistence-enabled>true
<paging-directory>data/paging</paging-directory>

<address-setting match="#">
<dead-letter-address>DLQ</dead-letter-address>
<expiry-address>ExpiryQ</expiry>
<expiry-delay>1000000</expiry>
<send-to-dla-on-no-route>false</send-to-dla-on-no-route>
<max-size-bytes>-1</max-size-bytes>
<page-size-bytes>10000000</page-size-bytes>
<address-full-policy>PAGE</address-full-policy>
</address-settings>


In my head, this would cause all messages on all queues to become Expired after 100 seconds. This would then go to the ExpiryQ. At this point the Expiry reaper thread would clean them up thus freeing up memory. 

This doesn't seem to be the case as it is still using all of the memory within about an hour. Am I missing a specific option to help with cleanup of expired messages to not consume all of the memory? Or am I doing something incorrectly? Thanks. 

Also - Would paging be a benefit for this? I have it disabled I believe via the "persistence-enabled" false flag I believe.