爱站网站长seo综合查询,网站建设制作介绍河南,北京网站优化体验,深圳龙华区属于哪个区activemq 内存为了有效使用ActiveMQ#xff0c;了解ActiveMQ如何管理内存和磁盘资源以处理非持久性消息和持久性消息非常重要。 ActiveMQ具有三个关键参数#xff0c;需要对其进行检查。 临时使用百分比 这是已用于假脱机非持久消息的已分配磁盘存储的百分比 非持久性消息… activemq 内存 为了有效使用ActiveMQ了解ActiveMQ如何管理内存和磁盘资源以处理非持久性消息和持久性消息非常重要。 ActiveMQ具有三个关键参数需要对其进行检查。 临时使用百分比 这是已用于假脱机非持久消息的已分配磁盘存储的百分比 非持久性消息是无法在代理重新启动后幸存的消息 店铺使用率 这是已用于存储持久性消息的已分配磁盘空间的百分比 内存使用率 这是已用于跟踪目标高速缓存消息等的代理分配内存的百分比。此值必须小于-Xmx最大JVM堆大小 本博客试图阐明如何计算单个节点ActiveMQ代理实例的存储温度和内存使用率。 我们使用ActiveMQ版本5.8.0进行此说明。 一旦清楚了ActiveMQ如何操作这些值便可以使用关键配置设置对ActiveMQ进行微调以处理以下用例。 大量目的地队列/主题 可以根据需要创建/删除目的地 消费缓慢 当消费者无法跟上消息的生成速度时这是一个巨大的问题。 讯息爆发 在短时间内Swift涌入大量具有巨大有效负载大小的消息 资源利用不当 很少有目的地消耗资源而导致其他人挨饿 扩展策略 如果您想知道如何水平调整ActiveMQ请参考Bosanac Dejan创建的幻灯片。 你可以在这里找到 它包含不同的ActiveMQ拓扑除了调整ActiveMQ的各种参数外还可以有效地用于满足批量吞吐量。 我发现它非常有用。 让我们继续深入…… 以下XML代码段来自配置activemq.xml。 为memoryUsagestoreUsage和tempUsage指定的值仅用于讨论目的。 systemUsagesystemUsagememoryUsagememoryUsage limit256 mb//memoryUsagestoreUsagestoreUsage limit512 mb//storeUsagetempUsagetempUsage limit256 mb//tempUsage/systemUsage/systemUsage 内存使用情况 代理可使用256MB的JVM内存。 不要与-Xmx参数混淆。 店铺使用情况 这是持久消息使用的磁盘空间使用KahaDB 临时用法 假设我们使用默认的KahaDB这是非持久消息使用的磁盘空间。 ActiveMQ将非持久消息假脱机到磁盘以防止代理用尽内存 了解临时用法 代理可用性对于消息基础结构至关重要。 因此 生产者流控制是一种保护机制可以防止失控的生产者在没有使用者或使用者无法跟上将消息产生到目的地的速率时将非持久性消息泵入目的地。 。 让我们以在本地代理实例中将有效负载大小为1MB的非持久消息生成为目标“ foo.bar”为例。 C:\apache-activemq-5.8.0\exampleant producer -Durltcp://localhost:61616 -Dtopicfalse -Dsubjectfoo.bar -Ddurablefalse -DmessageSize1048576 生产者最终因温度使用率达到100而挂起 由于消息是非持久性的因此将它们存储在磁盘上的tmp_storage中 ActiveMQ提供了一种机制来调整每个目标的内存使用情况。 在这里我们对启用了生产者流控制且目标内存限制为100MB的所有队列有一个通用策略同样这仅用于说明目的。 policyEntry queue optimizedDispatchtrue producerFlowControltrue cursorMemoryHighWaterMark30 memoryLimit100 mb 临时使用率计算如下 tmp_storage文件夹的大小/临时使用的内存限制* 100 因此在我们的情况下 265,025,856 /256 * 1024 * 1024* 100 99.8〜100如经纪人控制台中所示。 以下日志消息显示在activemq.log中 INFO | Usage(default:temp:queue://foo.bar:temp) percentUsage99%, usage268535808, limit268435456, percentUsageMinDelta1%;Parent:Usage(default:temp
) percentUsage100%, usage268535808, limit268435456, percentUsageMinDelta1%: 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 (blockingfor: 1421s)让我们再举一个例子…… 请考虑以下系统使用情况配置。 我们将tempUsage减少到50MB同时保留了相同的目的地级别策略。 systemUsagesystemUsagememoryUsagememoryUsage limit256 mb//memoryUsagestoreUsagestoreUsage limit512 mb//storeUsagetempUsagetempUsage limit50 mb//tempUsage/systemUsage/systemUsage 在这种情况下我们发现临时用量激增至191 temp_storage停止增长到接近96MB并且生产者挂起。 临时使用率是191因为95.5MB / 50 MB* 100其中95.5 MB是文件夹的大小而50MB是临时使用的限制。 目标的限制为100MB因此temp_storage不会超过目标。 造成这种混淆的原因是临时使用限制小于每个目标内存限制。 店铺使用情况 让我们对持久消息重复相同的测试。 系统使用情况配置如下 systemUsagesystemUsagememoryUsagememoryUsage limit256 mb//memoryUsagestoreUsagestoreUsage limit512 mb//storeUsagetempUsagetempUsage limit256 mb//tempUsage/systemUsage/systemUsage 每个目标策略如下 policyEntry queue optimizedDispatchtrue producerFlowControltrue cursorMemoryHighWaterMark30 memoryLimit100 mb 让我们将1MB持久消息生成到名为“ foo.bar”的队列中 C:\apache-activemq-5.8.0\exampleant producer -Durltcp://localhost:61616 -Dtopicfalse -Dsubjectfoo.bar -Ddurabletrue -DmessageSize1048576 生产者在512条消息后挂起 以下日志语句出现在代理日志文件中 INFO | Usage(default:store:queue://foo.bar:store) percentUsage99%, usage537210471, limit536870912, percentUsageMinDelta1%;Parent:Usage(default:st
ore) percentUsage100%, usage537210471, limit536870912,percentUsageMinDelta1%: 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如下所示。 由于消息是持久性的因此需要将它们保存到文件系统中。 商店使用限制为512MB。 上面的屏幕快照显示了kahadb文件夹其中持久消息为543 MB消息和其他数据库相关文件为512MB 内存使用情况 在上面的示例中内存使用百分比为11。 根据目标策略每个目标分配的内存为100MBcursorMemoryHighWaterMark 指定为30。因此100MB的30为30MB。 因此除了将其存储在KahaDB中之外还使用30MB将消息存储在内存中以加快处理速度。 。 内存使用限制配置为256MB。 所以30MB是256的11 30/256* 100〜11 因此如果要有9个这样的队列发生类似的情况那么我们将耗尽11* 9 99〜100的代理内存使用量 内存使用率是代理用于存储消息的内存量。 很多时候这可能会成为瓶颈因为一旦这个空间已满经纪人将使生产者停滞不前。 在快速处理和有效的内存管理之间需要权衡取舍。 如果我们在内存中保留更多消息则处理速度更快。 但是内存消耗将非常高。 相反如果消息保留在磁盘上则处理将变慢。 结论 我们在此博客中看到了ActiveMQ中存储临时和内存使用情况的工作方式。 无法为每个目标配置存储和临时使用的百分比而内存使用的百分比则可能是因为cursorMemoryHighWaterMark。 希望您发现此信息有用。 此处给出的示例仅用于说明目的并不意味着可以投入生产。 您将需要进行适当的容量规划并确定代理拓扑以实现最佳配置。 如有任何意见请随时与我们联系 资源资源 http://blog.raulkr.net/2012/08/demystifying-producer-flow-control-and.html http://tmielke.blogspot.com/2011/02/observations-on-activemqs-temp-storage.html http://activemq.apache.org/javalangoutofmemory.html http://www.slideshare.net/dejanb/advanced-messaging-with-apache-activemq -Bosanac Dejan http://www.pepperdust.org/?p150 http://stackoverflow.com/questions/2361541/how-do-you-scale-your-activemq-vertical 翻译自: https://www.javacodegeeks.com/2014/04/temp-store-and-memory-percent-usage-in-activemq.htmlactivemq 内存
