Чтобы эффективно использовать ActiveMQ, очень важно понять, как ActiveMQ управляет памятью и дисковыми ресурсами для обработки непостоянных и постоянных сообщений.
ActiveMQ имеет три ключевых параметра, которые необходимо контролировать.
- Темп Процент использования
- Это% назначенного дискового хранилища, которое использовалось для спулинга непостоянных сообщений.
- Непостоянные сообщения — это сообщения, которые не переживают перезапуск брокера.
- Хранить процент использования
- Это% назначенного дискового пространства, которое было использовано для хранения постоянных сообщений
- Процент использования памяти
- Это% назначенной памяти посредника, который использовался для отслеживания адресатов, кэширования сообщений и т. Д. Это значение должно быть меньше, чем -Xmx (максимальный размер кучи JVM)
В этом блоге делается попытка разъяснить, как рассчитывается использование хранилища, температуры и памяти для одного экземпляра узла ActiveMQ-узла. Мы используем ActiveMQ версии 5.8.0 для этого объяснения.
Как только мы проясним, как ActiveMQ использует эти значения, мы можем точно настроить ActiveMQ, используя ключевые параметры конфигурации, для обработки следующих случаев использования.
- Большое количество направлений (очередей / тем)
- Направления могут быть созданы / удалены по мере необходимости
- Медленные потребители
- Это огромная проблема, когда потребители не могут успевать за скоростью, с которой производятся сообщения.
- Взрыв сообщения
- Быстрый приток большого количества сообщений с огромным размером полезной нагрузки в течение короткого периода времени
- Неправильное использование ресурсов
- Мало мест назначения, которые поглощают ресурсы, заставляя других голодать
Стратегии масштабирования
Если вам интересно узнать, как ActiveMQ можно масштабировать по горизонтали, обратитесь к слайду, созданному Bosanac Dejan. Вы можете найти это здесь
Он содержит различные топологии ActiveMQ, которые могут эффективно использоваться для обеспечения пропускной способности тома в дополнение к различным параметрам для настройки ActiveMQ. Я нашел это чрезвычайно полезным.
Давайте копаться прямо в …
Следующий фрагмент XML взят из конфигурации activemq.xml. Значения, указанные для memoryUsage, storeUsage и tempUsage, предназначены только для обсуждения.
01
02
03
04
05
06
07
08
09
10
11
12
13
|
< systemUsage > < systemUsage > < memoryUsage > < memoryUsage limit = "256 mb" /> </ memoryUsage > < storeUsage > < storeUsage limit = "512 mb" /> </ storeUsage > < tempUsage > < tempUsage limit = "256 mb" /> </ tempUsage > </ systemUsage > </ systemUsage > |
- Использование памяти
- Для брокера доступно 256 МБ памяти JVM. Не путать с параметром -Xmx.
- Использование магазина:
- Это дисковое пространство, используемое постоянными сообщениями (с использованием KahaDB)
- Временное использование:
- Это дисковое пространство, используемое непостоянным сообщением, при условии, что мы используем KahaDB по умолчанию. ActiveMQ помещает непостоянные сообщения на диск, чтобы предотвратить нехватку памяти у брокера
Понимание временного использования
Доступность брокера имеет решающее значение для инфраструктуры сообщений. Следовательно, управление потоком производителя является механизмом защиты, который не позволяет сбежавшему производителю перекачивать непостоянные сообщения в пункт назначения, когда нет потребителей или когда потребитель (потребители) не в состоянии не отставать от скорости, с которой сообщения производятся в пункт назначения ,
Давайте рассмотрим пример создания непостоянных сообщений с размером полезной нагрузки 1 МБ в целевом «foo.bar» в экземпляре локального брокера.
1
|
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 предоставляет механизм для настройки использования памяти по месту назначения. Здесь у нас есть общая политика для всех очередей, в которых включено управление потоком производителя и предел памяти назначения составляет 100 МБ (опять же, это только для иллюстрации).
1
|
< policyEntry queue=">" optimizedDispatch="true" producerFlowControl="true" cursorMemoryHighWaterMark="30" memoryLimit="100 mb" > |
Темп% использования рассчитывается следующим образом:
(Размер лимита использования папки tmp_storage / temp) * 100
Итак, в нашем случае:
265,025,856 / (256 * 1024 * 1024) * 100 = 99,8 ~ 100%, как показано на консоли брокера.
Следующее сообщение журнала отображается в activemq.log
1
2
3
4
5
|
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 до 50 МБ, сохранив прежнюю политику уровня назначения.
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
< 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 перестает расти на уровне около 96 МБ, и производитель зависает ..
Процент временного использования составляет 191%, потому что (95,5 МБ / 50 МБ) * 100, где 95,5 МБ — это размер папки, а 50 МБ — это временное ограничение.
Назначение имеет ограничение в 100 МБ, поэтому temp_storage не превышает его. Это своего рода заблуждение, которое вызвано тем фактом, что ограничение временного использования меньше, чем ограничение на целевую память.
Использование магазина
Давайте повторим тот же тест с постоянными сообщениями.
Использование системы настраивается следующим образом:
01
02
03
04
05
06
07
08
09
10
11
12
13
14
|
< systemUsage > < systemUsage > < memoryUsage > < memoryUsage limit = "256 mb" /> </ memoryUsage > < storeUsage > < storeUsage limit = "512 mb" /> </ storeUsage > < tempUsage > < tempUsage limit = "256 mb" /> </ tempUsage > </ systemUsage > </ systemUsage > |
Политика в отношении пункта назначения выглядит следующим образом:
1
|
< policyEntry queue=">" optimizedDispatch="true" producerFlowControl="true" cursorMemoryHighWaterMark="30" memoryLimit="100 mb" > |
Давайте создадим 1 МБ постоянных сообщений в очередь с именем «foo.bar»
1
|
C:\apache-activemq-5.8.0\example>ant producer -Durl=tcp: //localhost :61616 -Dtopic= false -Dsubject=foo.bar -Ddurable= true -DmessageSize=1048576 |
Производитель зависает после 512 сообщений
Следующая запись журнала появляется в файле журнала брокера
1
2
3
|
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%, как показано ниже.
Поскольку сообщения являются постоянными, их необходимо сохранить в файловой системе. Ограничение использования магазина составляет 512 МБ.
На приведенном выше снимке экрана показана папка kahadb, в которой постоянные сообщения составляют 543 МБ (512 МБ для сообщений и других файлов, связанных с базой данных).
Использование памяти
В приведенном выше примере процент использования памяти равен 11. Как это произошло?
Согласно политике назначения, память, выделенная для назначения, составляет 100 МБ, а cursorMemoryHighWaterMark
указано 30. Таким образом, 30% от 100 МБ — это 30 МБ. Следовательно, 30 МБ используется для хранения сообщений в памяти для более быстрой обработки, а также для сохранения в KahaDB. ,
Ограничение использования памяти настроено на 256 МБ. Таким образом, 30 МБ это ~ 11% от 256
(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-vertically
Ссылка: | Темп, хранение и процент использования памяти в ActiveMQ от нашего партнера JCG Ашвини Кунтамуккала в |