為了有效使用ActiveMQ，了解ActiveMQ如何管理內存和磁盤資源以處理非持久性消息和持久性消息非常重要。

ActiveMQ具有三個關鍵參數，需要對其進行檢查。

臨時使用百分比

這是已用于假脫機非持久消息的已分配磁盤存儲的百分比

非持久性消息是無法在代理重新啟動后幸存的消息

店鋪使用率

這是已用于存儲持久性消息的已分配磁盤空間的百分比

內存使用率

這是已用于跟蹤目標，高速緩存消息等的代理分配的內存的百分比。此值必須小于-Xmx（最大JVM堆大小）

該博客試圖闡明如何計算單個節點ActiveMQ代理實例的存儲，溫度和內存使用率。 我們使用ActiveMQ版本5.8.0進行此說明。

一旦清楚了ActiveMQ如何操作這些值，就可以使用關鍵配置設置對ActiveMQ進行微調，以處理以下用例。

大量目的地（隊列/主題）

• 可以根據需要創建/刪除目的地

緩慢的消費者

• 當消費者無法跟上消息的生成速度時，這是一個巨大的問題。

訊息爆發

• 在短時間內Swift涌入大量具有巨大有效負載大小的消息

資源利用不當

• 很少有目的地消耗資源而導致其他人挨餓

擴展策略

如果您想知道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>

內存使用情況

代理可使用256MB的JVM內存。 不要與-Xmx參數混淆。

店鋪使用情況：

這是持久消息使用的磁盤空間（使用KahaDB）

臨時用法：

假設我們使用默認的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％而掛起

由于消息是非持久性的，因此它們將存儲在磁盤上的tmp_storage中

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 (blockingfor: 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％

temp_storage停止增長到接近96MB，并且生產者掛起。

臨時使用率是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％，如下所示。

由于消息是持久性的，因此需要將它們保存到文件系統中。 商店使用限制為512MB。

上面的屏幕快照顯示了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。
希望您發現此信息有用。 此處給出的示例僅用于說明目的，并不意味著可以投入生產。 您將需要進行適當的容量規劃，并確定代理拓撲以實現最佳配置。 如有任何意見，請隨時與我們聯系！

資源資源

• 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/?p=150
• 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.html

總結

以上是生活随笔為你收集整理的ActiveMQ中的温度，存储和内存使用百分比的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。