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...@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)u8...@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.
