activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From srasul <>
Subject Re: Memory Usage With No Subcribers and No Messages
Date Tue, 19 Jun 2007 14:31:42 GMT

Hi Jim,

my guess would be that the EnqueueCount is how many items were
queued/waiting to be dispached, and it seems quite high. if this value goes
up over time then there is your resource leak. some docs about activeMQ +
JMX is at:

my other guess would be that each message has to be dispatched to 20
consumers. and you have less producers than consumers. this would mean that
perhaps your dispatching to the consumers is taking too long. hence there is
buildup of messages causing this memory leak. for example if we scale your
setup down to 1 producer and 5 consumers, assuming you produce 1 messages
per sec and each message takes 1 second to consume per consumer then after 5
secs, you would have 4 messages waiting to be dispatched to the consumers.
after 10 secs 8 messages waiting to be dispatched and after 15 secs, 12
messages to be dispatched.

I hope i am on the right track... perhaps some experts could shed some



Jim_Cross wrote:
> Hi Saqib,
> Thanks for your reply.
> Unfortunately we're only using a single non-durable topic - no queues and
> no durable topics.
> Looking at the MBean for the topic after about an hour I see:
> DequeueCount: 472089
> DispatchCount: 472225
> EnqueueCount: 24139
> Does this sound normal? And do you know whether there's any documentation
> relating to the attributes exposed by the MBeans?
> srasul wrote:
>> Hi,
>> I am no activeMQ expert... but... this might be the "fast-producer &
>> slow-consumer" issue. If you use Queues, and there is fast producer and a
>> slow consumer, you will eventually run out of memory.
>> this is because JMS has guaranteed message delivery. meaning any message
>> you send must be delivered, one way or another. So the message is
>> persisted in memory until someone comes along and consumes it. this could
>> be why you are running out of memory. you can see this in JConsole's JMX
>> beans. check out how many messages were put into a queue and how many
>> were popped off it.
>> i guess the solution might be to:
>> - have messages that have short lifespan and are removed after a while if
>> no one consumes it. this may fix the issue, but could also just delay
>> when you run out memory
>> - use non-durable topics rather than queues where is message is discarded
>> if there is no-one around to consume it.
>> regards,
>> Saqib
>> Jim_Cross wrote:
>>> So I tried the recommendation in another thread:
>>>     <memoryManager>
>>>        <usageManager id="memory-manager" limit="1048576"/>
>>>     </memoryManager>
>>> And it ran with the 20 subscribers, 15 publishers, around 15 messages
>>> every 2 seconds for just over an hour before again running out of memory
>>> (see graph below).
>>> This is a serious problem for us, as it seems memory usage never settles
>>> down.
>>> Jim_Cross wrote:
>>>> Hi,
>>>> I'm using ActiveMQ 4.1.1 on a Linux box, standard configuration plus a
>>>> single additional topic.
>>>> If I start ActiveMQ, and don't start any subscribers or producers (so
>>>> no subscriptions and no messages sent to the topic), and take a look at
>>>> JConsole, I see the attached memory usage - every minute heap usage
>>>> goes from ~4mb up to ~13mb, then gets garbage collected back down to
>>>> 4mb.
>>>> Is this normal? 9mb seems like quite a lot of memory to be eating up
>>>> over the course of a minute when there's no activity at all.
>>>> The reason I started looking at this is that with approximately 20
>>>> non-durable subscribers, plus 15 producers each sending around 1
>>>> message every couple of seconds, it runs fine for bout 20 mins, then
>>>> hangs with 100% memory usage.
>>>> I'm going to increase the available memory to the broker, to see
>>>> whether it settles down at a max somewhere over 20mb.
>>>> Any insight into why ActiveMQ uses so much memory when there's no
>>>> activity, and whether there are any config changes I can make to alter
>>>> this, gratefully received.
>>>> Jim

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message