You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by eccrowe <ec...@dolby.com> on 2007/02/08 05:39:24 UTC

ActiveMQ Topic Memory Usage Requirements

Greetings,

I apologize in advance if this question has already been asked before, but
my forum search has not been fruitful in regards to this question as of yet.

The question I have is about the memory usage requirements with a
non-persistent topic.  We are running ActiveMQ 4.0-RC2 in an embedded
environment where most memory available on the system has been pre-allocated
to various processes including our JVM (128 MB).    The broker memory
manager has been setup such that its limit is at 10MB.

I believe that the entirety of this 10MB is included within our JVM, but
would appreciate a confirmation on that suspicion.  Stated a different way,
is there any RAM that must be allocated outside of the JVM for a topic
consumer to be able to adequately receive messages?  Will a consumer
possibly stop receiving messages altogether if there was adequate memory
pre-allocated to the JVM but not outside of its virtual machine?

Many thanks in advance.
-- 
View this message in context: http://www.nabble.com/ActiveMQ-Topic-Memory-Usage-Requirements-tf3191331s2354.html#a8859459
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Re: ActiveMQ Topic Memory Usage Requirements

Posted by James Strachan <ja...@gmail.com>.
There's a certain amount of RAM usage for the broker itself, then a
bit per destination used (as there are various data structures to deal
with connections, consumers, destinations etc) but they are fairly
lightweight. Then the broker tends to keep around a number of messages
in RAM as they are being dispatched to consumers.

Given the nature of GC, its always best you try running your
application and monitoring the heap over time to get a feel for what
the memory requirements are as its dependent on many factors (OS, JVM,
message volume/distribution, number of destinations & connections etc

One thing to be wary of in relatively low RAM environments for the
broker is prefetch configurations for connections...
http://activemq.apache.org/what-is-the-prefetch-limit-for.html

you probably wanna set that to something small (like 1) to avoid
connections & the broker keeping too many messages around. i.e.
trading slower performance for lower RAM usage.

Also be wary of slow consumers causing the broker to hang
http://activemq.apache.org/slow-consumer-handling.html

Generally speaking for high volume brokers - we recommend lots more
RAM than 10MB (we tend to default to 512MB for a stand alone broker
JVM) - but if you have a relativley low volume broker you might be
able to get away with just 10MB - but I'd try it out and monitor
actual RAM usage under typical traffic peaks first.

On 2/8/07, eccrowe <ec...@dolby.com> wrote:
>
> Greetings,
>
> I apologize in advance if this question has already been asked before, but
> my forum search has not been fruitful in regards to this question as of yet.
>
> The question I have is about the memory usage requirements with a
> non-persistent topic.  We are running ActiveMQ 4.0-RC2 in an embedded
> environment where most memory available on the system has been pre-allocated
> to various processes including our JVM (128 MB).    The broker memory
> manager has been setup such that its limit is at 10MB.
>
> I believe that the entirety of this 10MB is included within our JVM, but
> would appreciate a confirmation on that suspicion.  Stated a different way,
> is there any RAM that must be allocated outside of the JVM for a topic
> consumer to be able to adequately receive messages?  Will a consumer
> possibly stop receiving messages altogether if there was adequate memory
> pre-allocated to the JVM but not outside of its virtual machine?
>
> Many thanks in advance.
> --
> View this message in context: http://www.nabble.com/ActiveMQ-Topic-Memory-Usage-Requirements-tf3191331s2354.html#a8859459
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/