ActiveMQ 生产者生成堆转储答案

【问题标题】：ActiveMQ producer generating heapdumpActiveMQ 生产者生成堆转储
【发布时间】：2014-04-06 14:46:40
【问题描述】：

我们在 IBM AIX 机器上使用 Jboss FuseESB Active MQ。我们每天向消费者发送多达 10000 个请求。每个请求的大小约为 10Kb。我们每 3 天就会进行一次堆转储。这是 IBM 堆分析器的图像。

在生成堆之前，我认为 JMS 消息被消费者处理得很慢。提高JMS消费者处理速度的策略是什么。

编辑：

这是堆分析器的图像：

编辑：

我们正在使用嵌入式代理。这是我们正在使用的 activemq.xml：

<beans
  xmlns="http://www.springframework.org/schema/beans"
  xmlns:amq="http://activemq.apache.org/schema/core"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org /schema/beans/spring-beans-2.0.xsd
  http://activemq.apache.org/schema/core http://activemq.apache.org/schema/core/activemq-core.xsd">

<!-- Allows us to use system properties and fabric as variables in this configuration file -->
<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="properties">
        <bean class="org.fusesource.mq.fabric.ConfigurationProperties"/>
    </property>      
</bean>

<broker xmlns="http://activemq.apache.org/schema/core"
        brokerName="${broker-name}"
        dataDirectory="${data}"
        start="false">

    <destinationPolicy>
        <policyMap>
          <policyEntries>
            <policyEntry topic=">" producerFlowControl="true">
              <pendingMessageLimitStrategy>
                <constantPendingMessageLimitStrategy limit="1000"/>
              </pendingMessageLimitStrategy>
            </policyEntry>
            <policyEntry queue=">" producerFlowControl="true" queuePrefetch="1">
                  <deadLetterStrategy>
                       <individualDeadLetterStrategy queuePrefix="DLQ."/>
                  </deadLetterStrategy>
            </policyEntry>
          </policyEntries>
        </policyMap>
    </destinationPolicy>

    <managementContext>
        <managementContext createConnector="false"/>
    </managementContext>

    <persistenceAdapter>
        <kahaDB directory="${data}/kahadb"/>
    </persistenceAdapter> 


<!--

<plugins>
        <jaasAuthenticationPlugin configuration="karaf" />
    </plugins>
-->
    <systemUsage>
        <systemUsage>
            <memoryUsage>
                <memoryUsage limit="128 mb"/>
            </memoryUsage>
            <storeUsage>
                <storeUsage limit="100 gb"/>
            </storeUsage>
            <tempUsage>
                <tempUsage limit="50 gb"/>
            </tempUsage>
        </systemUsage>
    </systemUsage>


    <transportConnectors>
        <transportConnector name="openwire" uri="tcp://0.0.0.0:0?maximumConnections=1000"/>
    </transportConnectors>
</broker>
</beans>

【问题讨论】：

这里的细节很少。我是否正确假设您实际上使用嵌入式代理？另外，如果有的话，您的持久性配置是什么？因为在禁用持久性的情况下，您会强制代理将所有传输中的消息保留在内存中，这可以解释 OOM 问题。然而，即使使用更大的中间存储，如果消耗的速度比生产的速度慢，您显然会遇到麻烦，您应该考虑加快消费者的速度，为其提供更快的机器运行，或者将多个进程作为消费者附加到队列，如果你的架构允许的话。
我添加了activemq.xml进行编辑。我们也在 kahadb 中使用持久性。
从您的 heapdump 映像中不清楚谁拥有占用内存的对象。您可以在那里进行更多分析并将其添加到问题中吗？

标签： java activemq fuseesb heap-dump jbossfuse

【解决方案1】：

是否可能存在未启动的任何队列和/或持久主题订阅者，并且它们的消息保留在 JMS 代理中？

您应该浏览 JMS 目标，例如使用 JMX，并识别消息及其使用者。如果您检查了每个消费者都已正确配置并运行，请调试消息消耗如此缓慢的原因。

【讨论】：