activemq 內(nèi)存

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

ActiveMQ具有三個(gè)關(guān)鍵參數(shù)，需要對(duì)其進(jìn)行檢查。

臨時(shí)使用百分比

這是已用于假脫機(jī)非持久消息的已分配磁盤存儲(chǔ)的百分比

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

店鋪使用率

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

內(nèi)存使用率

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

本博客試圖闡明如何計(jì)算單個(gè)節(jié)點(diǎn)ActiveMQ代理實(shí)例的存儲(chǔ)，溫度和內(nèi)存使用率。 我們使用ActiveMQ版本5.8.0進(jìn)行此說明。

一旦清楚了ActiveMQ如何操作這些值，便可以使用關(guān)鍵配置設(shè)置對(duì)ActiveMQ進(jìn)行微調(diào)，以處理以下用例。

大量目的地（隊(duì)列/主題）

• 可以根據(jù)需要?jiǎng)?chuàng)建/刪除目的地

消費(fèi)緩慢

• 當(dāng)消費(fèi)者無法跟上消息的生成速度時(shí)，這是一個(gè)巨大的問題。

訊息爆發(fā)

• 在短時(shí)間內(nèi)Swift涌入大量具有巨大有效負(fù)載大小的消息

資源利用不當(dāng)

• 很少有目的地消耗資源而導(dǎo)致其他人挨餓

擴(kuò)展策略

如果您想知道如何水平調(diào)整ActiveMQ，請(qǐng)參考Bosanac Dejan創(chuàng)建的幻燈片。 你可以在這里找到

它包含不同的ActiveMQ拓?fù)?#xff0c;除了調(diào)整ActiveMQ的各種參數(shù)外，還可以有效地用于滿足批量吞吐量。 我發(fā)現(xiàn)它非常有用。

讓我們繼續(xù)深入……

以下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>

內(nèi)存使用情況

代理可使用256MB的JVM內(nèi)存。 不要與-Xmx參數(shù)混淆。

店鋪使用情況：

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

臨時(shí)用法：

假設(shè)我們使用默認(rèn)的KahaDB，這是非持久消息使用的磁盤空間。 ActiveMQ將非持久消息假脫機(jī)到磁盤，以防止代理用盡內(nèi)存

了解臨時(shí)用法

代理可用性對(duì)于消息基礎(chǔ)結(jié)構(gòu)至關(guān)重要。 因此， 生產(chǎn)者流控制是一種保護(hù)機(jī)制，可以防止失控的生產(chǎn)者在沒有使用者或使用者無法跟上將消息產(chǎn)生到目的地的速率時(shí)將非持久性消息泵入目的地。 。

讓我們以在本地代理實(shí)例中將有效負(fù)載大小為1MB的非持久消息生成為目標(biāo)“ foo.bar”為例。

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

生產(chǎn)者最終因溫度％使用率達(dá)到100％而掛起

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

ActiveMQ提供了一種機(jī)制來調(diào)整每個(gè)目標(biāo)的內(nèi)存使用情況。 在這里，我們對(duì)啟用了生產(chǎn)者流控制且目標(biāo)內(nèi)存限制為100MB的所有隊(duì)列有一個(gè)通用策略（同樣，這僅用于說明目的）。

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

臨時(shí)使用率計(jì)算如下：

（tmp_storage文件夾的大小/臨時(shí)使??用的內(nèi)存限制）* 100

因此，在我們的情況下：

265,025,856 /（256 * 1024 * 1024）* 100 = 99.8?100％，如經(jīng)紀(jì)人控制臺(tái)中所示。

以下日志消息顯示在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)

讓我們?cè)倥e一個(gè)例子……

請(qǐng)考慮以下系統(tǒng)使用情況配置。 我們將tempUsage減少到50MB，同時(shí)保留了相同的目的地級(jí)別策略。

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

在這種情況下，我們發(fā)現(xiàn)臨時(shí)用量激增至191％

temp_storage停止增長到接近96MB，并且生產(chǎn)者掛起。

臨時(shí)使用率是191％，因?yàn)?#xff08;95.5MB / 50 MB）* 100，其中95.5 MB是文件夾的大小，而50MB是臨時(shí)使用的限制。

目標(biāo)的限制為100MB，因此temp_storage不會(huì)超過目標(biāo)。 造成這種混淆的原因是，臨時(shí)使用限制小于每個(gè)目標(biāo)內(nèi)存限制。

店鋪使用情況

讓我們對(duì)持久消息重復(fù)相同的測試。

系統(tǒng)使用情況配置如下：

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

每個(gè)目標(biāo)策略如下：

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

讓我們將1MB持久消息生成到名為“ foo.bar”的隊(duì)列中

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

生產(chǎn)者在512條消息后掛起

以下日志語句出現(xiàn)在代理日志文件中

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)

經(jīng)紀(jì)人商店的使用率為100％，如下所示。

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

上面的屏幕快照顯示了kahadb文件夾，其中持久消息為543 MB（消息和其他數(shù)據(jù)庫相關(guān)文件為512MB）

內(nèi)存使用情況

在上面的示例中，內(nèi)存使用百分比為11。

根據(jù)目標(biāo)策略，每個(gè)目標(biāo)分配的內(nèi)存為100MB，cursorMemoryHighWaterMark
指定為30。因此100MB的30％為30MB。 因此，除了將其存儲(chǔ)在KahaDB中之外，還使用30MB將消息存儲(chǔ)在內(nèi)存中以加快處理速度。 。

內(nèi)存使用限制配置為256MB。 所以30MB是256的11％

（30/256）* 100?11％

因此，如果要有9個(gè)這樣的隊(duì)列發(fā)生類似的情況，那么我們將耗盡11％* 9 = 99％?100％的代理內(nèi)存使用量

內(nèi)存使用率是代理用于存儲(chǔ)消息的內(nèi)存量。 很多時(shí)候，這可能會(huì)成為瓶頸，因?yàn)橐坏┻@個(gè)空間已滿，經(jīng)紀(jì)人將使生產(chǎn)者停滯不前。 在快速處理和有效的內(nèi)存管理之間需要權(quán)衡取舍。

如果我們?cè)趦?nèi)存中保留更多消息，則處理速度更快。 但是，內(nèi)存消耗將非常高。 相反，如果消息保留在磁盤上，則處理將變慢。

結(jié)論

我們?cè)诖瞬┛椭锌吹搅薃ctiveMQ中存儲(chǔ)，臨時(shí)和內(nèi)存使用情況的工作方式。 無法為每個(gè)目標(biāo)配置存儲(chǔ)和臨時(shí)使用的百分比，而內(nèi)存使用的百分比則可能是因?yàn)閏ursorMemoryHighWaterMark。
希望您發(fā)現(xiàn)此信息有用。 此處給出的示例僅用于說明目的，并不意味著可以投入生產(chǎn)。 您將需要進(jìn)行適當(dāng)?shù)娜萘恳?guī)劃，并確定代理拓?fù)湟詫?shí)現(xiàn)最佳配置。 如有任何意見，請(qǐng)隨時(shí)與我們聯(lián)系！

資源資源

• 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 內(nèi)存

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。