activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TMcCabe <team...@hotmail.com>
Subject Re: ActiveMQ 5.3.0 cpu usage goes to zero
Date Fri, 26 Mar 2010 23:39:02 GMT

Thanks for the reply.

Nope. I was trying to look at the documentation but didn't understand how to
turn that on.
Please let me know how to.

There is no thread dump though.
I'm a rookie, so how to get a thread dump.

It seems as though ActiveMQ restarts itself. Right after the CPU usage goes
to 0 it takes some seconds and AMQ starts right back up.

T.


bsnyder wrote:
> 
> On Fri, Mar 26, 2010 at 8:16 PM, TMcCabe <team_mc@hotmail.com> wrote:
>>
>>
>> Config file:
>>    <broker xmlns="http://activemq.apache.org/schema/core"
>> brokerName="localhost" dataDirectory="${activemq.base}/data"
>> advisorySupport="false">
>>
>>        <!--
>>            The managementContext is used to configure how ActiveMQ is
>> exposed in
>>            JMX. By default, ActiveMQ uses the MBean server that is
>> started
>> by
>>            the JVM. For more information, see:
>>
>>            http://activemq.apache.org/jmx.html
>>        -->
>>        <managementContext>
>>            <managementContext createConnector="false"/>
>>        </managementContext>
>>
>>        <!--
>>            Configure message persistence for the broker. The default
>> persistence
>>            mechanism is the KahaDB store (identified by the kahaDB tag).
>>            For more information, see:
>>
>>            http://activemq.apache.org/persistence.html
>>            <amqPersistenceAdapter
>> directory="${activemq.base}/data/activemq-data" maxFileLength="64mb"/>
>>            <kahaDB directory="${activemq.base}/data/kahadb"
>> indexWriteBatchSize="10000" indexCacheSize="1000"/>
>>            indexWriteBatchSize="10000" indexCacheSize="1000"
>> enableIndexWriteAsync="true" journalMaxFileLength="64mb"
>>        -->
>>        <persistenceAdapter>
>>            <amqPersistenceAdapter
>> directory="${activemq.base}/data/activemq-data" syncOnWrite="false" />
>>        </persistenceAdapter>
>>
>>
>>        <!--
>>                        For better performances use VM cursor and small
>> memory limit.
>>                        For more information, see:
>>
>>            http://activemq.apache.org/message-cursors.html
>>
>>            Also, if your producer is "hanging", it's probably due to
>> producer flow control.
>>            For more information, see:
>>            http://activemq.apache.org/producer-flow-control.html
>>
>>             optimizedDispatch="true"
>>        -->
>>
>>        <destinationPolicy>
>>            <policyMap>
>>              <policyEntries>
>>                <policyEntry topic=">" producerFlowControl="false"
>> memoryLimit="1mb">
>>                </policyEntry>
>>                <policyEntry queue=">" producerFlowControl="false"
>> memoryLimit="1mb" >
>>                  <dispatchPolicy>
>>                    <strictOrderDispatchPolicy/>
>>                  </dispatchPolicy>
>> <!--                  <pendingMessageLimitStrategy>
>>                      <prefetchRatePendingMessageLimitStrategy
>> multiplier="2.5"/>
>>                  </pendingMessageLimitStrategy>
>> -->
>>                 <!-- Use VM cursor for better latency
>>                  <pendingQueuePolicy>
>>                    <vmQueueCursor/>
>>                  </pendingQueuePolicy>
>>                       For more information, see:
>>
>>                       http://activemq.apache.org/message-cursors.html
-->
>>                </policyEntry>
>>              </policyEntries>
>>            </policyMap>
>>        </destinationPolicy>
>>
>>         <!--
>>            The systemUsage controls the maximum amount of space the
>> broker
>> will
>>            use before slowing down producers. For more information, see:
>>
>>            http://activemq.apache.org/producer-flow-control.html
>>                <tempUsage>
>>                    <tempUsage limit="256 mb"/>
>>                </tempUsage>
>>                -->
>>
>>        <systemUsage>
>>            <systemUsage sendFailIfNoSpace="true">
>>                <memoryUsage>
>>                    <memoryUsage limit="256 mb"/>
>>                </memoryUsage>
>>                <storeUsage>
>>                    <storeUsage limit="60 gb" name="store"/>
>>                </storeUsage>
>>                <tempUsage>
>>                    <tempUsage limit="256 mb"/>
>>                </tempUsage>
>>            </systemUsage>
>>        </systemUsage>
>>
>>        <!--
>>            The transport connectors expose ActiveMQ over a given protocol
>> to
>>            clients and other brokers. For more information, see:
>>
>>            http://activemq.apache.org/configuring-transports.html
>>        -->
>>        <transportConnectors>
>>            <transportConnector name="openwire"
>> uri="tcp://0.0.0.0:61616?wireFormat.maxInactivityDuration=-1&wireFormat.tightEncodingEnabled=false"
>> />
>>        </transportConnectors>
>>
>>    </broker>
>>
>>
>>
>>
>>
>> I have 48 Q's with 64 producers with a consumer for each Q. Each producer
>> sending a byte message (persistent) of approx 7K to each of the 48 Q's
>> every
>> 1.5 seconds.
>>
>> I see the producer hang and the consumer hang as AMQ CPU usage drops to 0
>> after 4 minutes. Using jconsole to monitor AMQ performance.
>>
>> Any help most appreciated as to what may be happening.
>> Am I correct to assume that AMQ cannot handle the load?
>> Machine (RHEL v5) 2Core CPU, 4G RAM.
>>
>> Look around the forums for similar problems and tried to adjust config
>> files.
>> Able to get it consistent if using the default store but with one
>> horrible
>> side effect in that my producer may not be able to send a message for 2
>> to 3
>> seconds (must send every 1.5)
> 
> Have you enabled debug level logging yet to examine the output from
> the broker when it's hanging? This is the first step because it could
> be that the available memory is being exhausted.
> 
> The only other way to determine what is happening is to see what is
> running when the hang occurs. You can do this by grabbing two or three
> thread dumps from the broker when it's hanging. Then we'll need to
> examine them to see where it's hanging.
> 
> Bruce
> -- 
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
> 
> ActiveMQ in Action: http://bit.ly/2je6cQ
> Blog: http://bruceblog.org/
> Twitter: http://twitter.com/brucesnyder
> 
> 

-- 
View this message in context: http://old.nabble.com/ActiveMQ-5.3.0-cpu-usage-goes-to-zero-tp28047427p28049072.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message