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
