<div class="wiki-content maincontent"><p>Ok, this is manageable. It is possible to configure just about all of the memory utilisation of ActiveMQ. The first thing to determine is what part of the system is running out of memory. Is it the JVM, the broker, the consumers or the producers? </p>
<structured-macro ac:macro-id="1e867ae9-192f-43d2-b551-5889fe88e50a" ac:name="note" ac:schema-version="1"><rich-text-body>
<p>This entry refers to ActiveMQ versions 5.1.x and greater.</p></rich-text-body></structured-macro>

<h4>Memory</h4>
<h5>JVM Memory </h5>
<p>Try running the broker in a standalone JVM using <code>bin/activemq</code>. Note the default JVM heap size option that is passed to the Java executable by the script (the exact options may depend upon the JVM that you are using, the examples are for the Sun JVM).</p>
<ul><li>-Xmx: If your OS has more available memory, consider increasing the total heap memory available to the broker JVM. Note that the JVM will require more memory than the -Xmx value. Thread stacks and the JMVs internal classes will consume additional memory.</li><li>-Xss: If you have <link ac:anchor="Number of Threads"><link-body>massive numbers of threads</link-body></link> in the Broker JVM, consider reducing the default JVM stack size of each thread with the -Xss option.</li></ul>


<p>If you are running an embedded broker or in a third party container, ensure that the hosting JVM has appropriate values for the maximum heap and stack sizes.</p>

<h5>Broker Memory </h5>
<p>The memory that the broker is allowed to use is not determined by the amount of memory allocated to the JVM. Although the broker is constrained by the amount of memory given to the JVM, the broker manages its memory independently. That is, the broker does not just simply use up all of the memory in the JVM and then die with an OutOfMemory exception. This is where you need to understand the <link ac:anchor="System usage"><page ri:content-title="Producer Flow Control"></page><link-body>systemUsage</link-body></link> memory limit and the per destination memory limit. </p>

<p>The memory in ActiveMQ works in a tiered fashion that flows from the JVM -&gt; Broker -&gt; broker features. E.g., the total amount of destination memory limits placed cannot exceed the memory limit of the broker. </p>

<h4>Consumer</h4>
<p>Along with message size, the <link><page ri:content-title="What is the Prefetch Limit For?"></page><link-body>prefetch limit</link-body></link> is main reason a consumer will <link ac:anchor="Ram versus Performance tradeoff"><page ri:content-title="What is the Prefetch Limit For?"></page><link-body>run out of memory</link-body></link>. Reducing the prefetch value will reduce the amount of messages queued/stored in memory on the Consumer.</p>

<h4>Producer</h4>
<p>Unless message size exceeds resource limits, a producer should not run out of memory. A producer may notice the effect of memory limit enforcement by the broker in the form of <link><page ri:content-title="My Producer Blocks"></page><link-body>blocking</link-body></link>.</p>


<h4>Other </h4>

<h5>Spooling Messages to Disk</h5>
<p>Fast dispatch of messages is only possible when messages are stored in memory. When consumers are slow or absent, memory can quickly become exhausted. <br clear="none">
The Broker (using <link><page ri:content-title="Message Cursors"></page></link>) will spool non-persistent messages to disk when the default memory usage threshold for a destination is reached. This threshold value is specified to the Broker via the &lt;memoryUsage&gt; section of the &lt;systemUsage&gt; configuration in <link><page ri:content-title="XML Configuration"></page><link-body>activemq.xml</link-body></link>. This feature allows producers to continue sending messages when there are slow consumers without exhausting available memory or reverting to <link><page ri:content-title="Producer Flow Control"></page><link-body>producer flow control</link-body></link>. In the case of multiple destinations, the combined default memory thresholds may be excessive and they may exceed available memory. In such a case it may make sense to reduce the memory usage 'limit' threshold at which messages are spooled to disk. An alternative option is to configure the 'precentUsage' rather than the absolute usage 'limit'. In this way, memory usage can be confined to a fixed percentage of available memory.</p>

<p>More specific per destination memoryUsage limits can be specified in <link><page ri:content-title="XML Configuration"></page><link-body>activemq.xml</link-body></link> using <link><page ri:content-title="Per Destination Policies"></page></link>. Some further examples of &lt;destinationPolicy&gt; map entries can be found in the <link><page ri:content-title="Message Cursors"></page></link> reference.</p>

<h5>Number of Threads</h5>
<p>By default, ActiveMQ uses a dedicated thread per destination. If there are large numbers of Destinations there will be a large number of threads and their associated memory resource usage. ActiveMQ can be configured to use a thread pool through the use of the system property: -Dorg.apache.activemq.UseDedicatedTaskRunner=false. This is currently specified in the activemq start script via ACTIVEMQ_OPTS. Using a thread pool can restrict the number of threads required by ActiveMQ and hence reduce memory usage.</p>

<h5>Really Large Messages</h5>
<p>When your message are really large such that you can only allow a few messages in memory at at time, the <link><page ri:content-title="Per Destination Policies"></page></link> maxPageSize and lazyDispatch can help. maxPageSize controls the amount of messages that are paged into memory for dispatch while lazyDispatch augments that value using the prefetch capacity of the current consumer list. With a prefetch of 1, a single consumer and lazyDispatch, only one message at a time would be loaded into memory at a time.</p>

<h5>Leaking JMS resources</h5>
<p>This is the most obvious one for Consumers or Producers; repeatedly obtaining a Session or MessageProducer or MessageConsumer and not closing it. With a java.lang.OutOfMemory, verifying (again) that all not in use JMS resources are released, is worth the time. If you have multiple threads in your application, consider using the <a shape="rect" href="http://activemq.apache.org/maven/activemq-core/apidocs/org/apache/activemq/pool/PooledConnectionFactory.html">PooledConnectionFactory</a> as this will allow JMS resource to be safely shared among threads that follow the pattern: </p>

<structured-macro ac:macro-id="62a3f40f-6247-4ef1-9ebc-da66cc21ca35" ac:name="code" ac:schema-version="1"><plain-text-body>
obtainJmsResource(); 

try 
{ 
    useJmsResource() 
} finally { 
    releaseJmsResource(); 
} 
</plain-text-body></structured-macro>

<p>If you are using ActiveMQ via <link><page ri:content-title="Spring Support"></page></link> or with JMSTemplates, be sure to check you are not falling for any of the <link><page ri:content-title="JmsTemplate Gotchas"></page></link>. It may also be worth recapping on <link><page ri:content-title="How do I use JMS efficiently"></page></link>.</p></div>