ActiveMQ中的温度,存储和内存使用百分比

为了有效使用ActiveMQ,了解ActiveMQ如何管理内存和磁盘资源以处理非持久性消息和持久性消息非常重要。

ActiveMQ具有三个关键参数,需要对其进行检查。

ActiveMQ中的温度,存储和内存使用百分比

  1. 临时使用百分比
    1. 这是已用于假脱机非持久消息的已分配磁盘存储的百分比
    2. 非持久性消息是无法在代理重新启动后幸存的消息
  2. 店铺使用率
    1. 这是已用于存储持久性消息的已分配磁盘空间的百分比
  3. 内存使用率
    1. 这是已用于跟踪目标,高速缓存消息等的代理分配的内存的百分比。此值必须小于-Xmx(最大JVM堆大小)

该博客试图阐明如何计算单个节点ActiveMQ代理实例的存储,温度和内存使用率。 我们使用ActiveMQ版本5.8.0进行此说明。

一旦清楚了ActiveMQ如何操作这些值,就可以使用关键配置设置对ActiveMQ进行微调,以处理以下用例。

  1. 大量目的地(队列/主题)
    • 可以根据需要创建/删除目的地
  2. 缓慢的消费者
    • 当消费者无法跟上消息的生成速度时,这是一个巨大的问题。
  3. 讯息爆发
    • 在短时间内Swift涌入大量具有巨大有效负载大小的消息
  4. 资源利用不当
    • 很少有目的地消耗资源而导致其他人挨饿

扩展策略

如果您想知道ActiveMQ如何水平缩放,请参考Bosanac Dejan创建的幻灯片。 你可以在这里找到

它包含不同的ActiveMQ拓扑,除了调整ActiveMQ的各种参数外,还可以有效地用于满足批量吞吐量。 我发现它非常有用。

让我们直接在...

以下XML代码段来自配置activemq.xml。 为memoryUsage,storeUsage和tempUsage指定的值仅用于讨论目的。

 <systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="256 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="512 mb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="256 mb"/>
                </tempUsage>
            </systemUsage>
          </systemUsage>
  1. 内存使用情况
    1. 代理可使用256MB的JVM内存。 不要与-Xmx参数混淆。
  2. 店铺使用情况:
    1. 这是持久消息使用的磁盘空间(使用KahaDB)
  3. 临时用法:
    1. 假设我们使用默认的KahaDB,这是非持久消息使用的磁盘空间。 ActiveMQ将非持久消息假脱机到磁盘,以防止代理用尽内存

了解临时用法

代理可用性对于消息基础结构至关重要。 因此, 生产者流控制是一种保护机制,可以防止失控的生产者在没有使用者或使用者无法跟上将消息产生到目的地的速率时将非持久消息泵入目的地。 。

让我们以在本地代理实例中将有效负载大小为1MB的非持久消息生成为目标“ foo.bar”为例。

C:\apache-activemq-5.8.0\example>ant producer -Durl=tcp://localhost:61616 -Dtopic=false -Dsubject=foo.bar -Ddurable=false -DmessageSize=1048576

生产商最终因温度%使用率达到100%而挂起

ActiveMQ中的温度,存储和内存使用百分比
由于消息是非持久性的,因此它们将存储在磁盘上的tmp_storage中

ActiveMQ中的温度,存储和内存使用百分比
ActiveMQ提供了一种机制,可以调整每个目标的内存使用情况。 在这里,我们对启用了生产者流控制且目标内存限制为100MB的所有队列有一个通用策略(同样,这仅用于说明目的)。

<policyEntry queue=">" optimizedDispatch="true" producerFlowControl="true" cursorMemoryHighWaterMark="30" memoryLimit="100 mb" > 

临时使用率计算如下:

(tmp_storage文件夹的大小/临时使​​用的内存限制)* 100

因此,在我们的情况下:

265,025,856 /(256 * 1024 * 1024)* 100 = 99.8〜100%,如经纪人控制台中所示。

以下日志消息显示在activemq.log中

INFO | Usage(default:temp:queue://foo.bar:temp) percentUsage=99%, usage=268535808, limit=268435456, percentUsageMinDelta=1%;Parent:Usage(default:temp
) percentUsage=100%, usage=268535808, limit=268435456, percentUsageMinDelta=1%: Temp Store is Full (99% of 268435456). Stopping producer (ID:AKUNTAMU-
1-61270-1388528939599-1:1:1:1) to prevent flooding queue://foo.bar. See http://activemq.apache.org/producer-flow-control.html for more info (blocking

for: 1421s)

让我们再举一个例子……

请考虑以下系统使用情况配置。 我们将tempUsage减少到50MB,同时保留了相同的目的地级别策略。

 <systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="256 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="512 mb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="50 mb"/>
                </tempUsage>
            </systemUsage>

        </systemUsage>
   

在这种情况下,我们发现临时使用率增加到191%

ActiveMQ中的温度,存储和内存使用百分比

temp_storage停止增长到接近96MB,并且生产者挂起。

ActiveMQ中的温度,存储和内存使用百分比

临时使用率是191%,因为(95.5MB / 50 MB)* 100,其中95.5 MB是文件夹的大小,50MB是临时使用的限制。

目标的限制为100MB,因此temp_storage不会超过目标。 造成这种混乱的原因是,临时使用限制小于每个目标内存限制。

店铺使用情况

让我们对持久消息重复相同的测试。

系统使用情况配置如下:

 <systemUsage>
            <systemUsage>
                <memoryUsage>
                    <memoryUsage limit="256 mb"/>
                </memoryUsage>
                <storeUsage>
                    <storeUsage limit="512 mb"/>
                </storeUsage>
                <tempUsage>
                    <tempUsage limit="256 mb"/>
                </tempUsage>
            </systemUsage>

          </systemUsage>

每个目标策略如下:

<policyEntry queue=">" optimizedDispatch="true" producerFlowControl="true" cursorMemoryHighWaterMark="30" memoryLimit="100 mb" > 

让我们将1MB持久消息生成到名为“ foo.bar”的队列中

C:\apache-activemq-5.8.0\example>ant producer -Durl=tcp://localhost:61616 -Dtopic=false -Dsubject=foo.bar -Ddurable=true -DmessageSize=1048576

生产者在512条消息后挂起

以下日志语句出现在代理日志文件中

 INFO | Usage(default:store:queue://foo.bar:store) percentUsage=99%, usage=537210471, limit=536870912, percentUsageMinDelta=1%;Parent:Usage(default:st
ore) percentUsage=100%, usage=537210471, limit=536870912,percentUsageMinDelta=1%: Persistent store is Full, 100% of 536870912. Stopping producer (ID: AKUNTAMU-1-31754-1388571228628-1:1:1:1) to prevent flooding queue://foo.bar. See http://activemq.apache.org/producer-flow-control.html for more info (
blocking for: 155s)

经纪人商店的使用率为100%,如下所示。

ActiveMQ中的温度,存储和内存使用百分比

由于消息是持久性的,因此需要将它们保存到文件系统中。 商店使用限制为512MB。

ActiveMQ中的温度,存储和内存使用百分比

上面的屏幕快照显示了kahadb文件夹,其中持久消息为543 MB(消息和其他数据库相关文件为512MB)

内存使用情况

在上面的示例中,内存使用率为11。

根据目标策略,每个目标分配的内存为100MB,cursorMemoryHighWaterMark
指定为30。因此100MB的30%为30MB。 因此,除了将消息存储在KahaDB中之外,还使用30MB将消息存储在内存中以进行更快的处理。

内存使用限制配置为256MB。 所以30MB是256的11%

(30/256)* 100〜11%

因此,如果要有9个这样的队列发生类似的情况,那么我们将耗尽11%* 9 = 99%〜100%的代理内存使用量

内存使用率是代理用于存储消息的内存量。 很多时候,这可能会成为瓶颈,因为一旦这个空间已满,经纪人将使生产者停滞不前。 在快速处理和有效的内存管理之间需要权衡取舍。

如果我们在内存中保留更多消息,则处理速度更快。 但是,内存消耗将非常高。 相反,如果消息保留在磁盘上,则处理将变慢。

结论

我们在此博客中看到了ActiveMQ中存储,临时和内存使用情况的工作方式。 无法为每个目标配置存储和临时使用的百分比,而内存使用的百分比则可能是因为cursorMemoryHighWaterMark。
希望您发现此信息有用。 此处给出的示例仅用于说明目的,并不意味着可以投入生产。 您将需要进行适当的容量规划,并确定代理拓扑以实现最佳配置。 如有任何意见,请随时与我们联系!

资源资源

翻译自: https://www.javacodegeeks.com/2014/04/temp-store-and-memory-percent-usage-in-activemq.html