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:40:41 GMT

nm...
This is how to turn on debug log correct?

log4j.logger.org.apache.activemq=DEBUG





TMcCabe wrote:
> 
> 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-tp28047427p28049080.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message