Статьи

Temp, Store и процент использования памяти в ActiveMQ


Чтобы эффективно использовать ActiveMQ, очень важно понять, как ActiveMQ управляет памятью и дисковыми ресурсами для обработки непостоянных и постоянных сообщений. 

ActiveMQ имеет три ключевых параметра, которые необходимо контролировать. 

  1. Темп Процент использования
    1. Это% назначенного дискового хранилища, которое использовалось для спулинга непостоянных сообщений.
    2. Непостоянные сообщения — это сообщения, которые не сохраняются после перезапуска 
  2. Хранить процент использования
    1. Это% назначенного дискового пространства, которое было использовано для хранения постоянных сообщений
  3. Процент использования памяти
    1. Это% назначенной памяти посредника, который использовался для отслеживания адресатов, кэширования сообщений и т. Д. Это значение должно быть меньше, чем -Xmx (максимальный размер кучи JVM)

В этом блоге делается попытка разъяснить, как рассчитывается использование хранилища, температуры и памяти для одного экземпляра узла ActiveMQ-узла. Мы используем ActiveMQ версии 5.8.0 для этого объяснения. 

Как только мы проясним, как ActiveMQ использует эти значения, мы можем точно настроить ActiveMQ, используя ключевые параметры конфигурации, для обработки следующих случаев использования. 

  1. Большое количество направлений (очередей / тем)
  • Направления могут быть созданы / удалены по мере необходимости
  • Медленные потребители
    • Это огромная проблема, когда потребители не могут успевать за скоростью, с которой производятся сообщения. 
  • Взрыв сообщения
    • Быстрый приток большого количества сообщений с огромным размером полезной нагрузки в течение короткого периода времени
  • Неправильное использование ресурсов
    • Мало мест назначения, которые поглощают ресурсы, заставляя других голодать

    Стратегии масштабирования


    Если вам интересно узнать, как 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. Для брокера доступно 256 МБ памяти JVM. Не путать с параметром -Xmx.
    2. Использование магазина: 
      1. Это дисковое пространство, используемое постоянными сообщениями (с использованием KahaDB)
    3. Временное использование: 
      1. Это дисковое пространство, используемое непостоянным сообщением, при условии, что мы используем KahaDB по умолчанию. ActiveMQ помещает непостоянные сообщения на диск, чтобы предотвратить нехватку памяти у брокера

    Понимание временного использования

    Доступность брокера очень важна для инфраструктуры сообщений. Следовательно,
    управление потоком производителя является механизмом защиты, который не позволяет сбежавшему производителю перекачивать непостоянные сообщения в пункт назначения, когда нет потребителей или когда потребитель (потребители) не в состоянии не отставать от скорости, с которой сообщения производятся в пункт назначения ,

    Давайте рассмотрим пример создания непостоянных сообщений с размером полезной нагрузки 1 МБ в целевом «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 предоставляет механизм для настройки использования памяти по месту назначения. Здесь у нас есть общая политика для всех очередей, в которых включено управление потоком производителя и предел памяти назначения составляет 100 МБ (опять же, это только для иллюстрации).

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

    Temp% использования рассчитывается следующим образом:

    (Размер папки tmp_storage / ограничение использования памяти temp) * 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 до 50 МБ, сохранив прежнюю политику уровня назначения.

            <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 МБ, и производитель зависает.
    Temp percent usage is 191% because (95.5MB / 50 MB)*100 where 95.5 MB is size of the folder and 50MB is temp usage limit. 
    The destination has a limit of 100MB so the temp_storage didn’t grow past it. It is sort of confusing which is caused by the fact that temp usage limit is less that per destination memory limit. 

    Store Usage

    Let’s repeat the same test with persistent messages.

    The system usage is configured as follows:

             <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" > 

    Давайте создадим 1 МБ постоянных сообщений в очередь с именем «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%, как показано ниже.

    Поскольку сообщения являются постоянными, их необходимо сохранить в файловой системе. Ограничение использования магазина составляет 512 МБ. 

    The above screenshot shows the kahadb folder where persistent messages is 543 MB (512MB for the messages and other database related files).

    Memory Usage

    In the above example, the memory usage percentage is 11. How did that come about?

    As per the destination policy, the memory allocated per destination is 100MB and the cursorMemoryHighWaterMark is specified to be 30. So 30% of 100MB is 30MB. Hence 30MB is used to store messages in memory for faster processing in addition to be being stored in the KahaDB.

    The memory usage limit is configured to be 256MB. So 30MB is ~ 11% of 256
    (30/256) * 100 ~ 11%
    So if we were to have 9 such queues where similar situation was to occur then we would have exhausted broker memory usage as 11 % * 9 = 99% ~ 100% 

    Memory usage is the amount of memory used by the broker for storing messages. Many a times, this can become a bottleneck as once this space is full, the broker will stall the producers.  There are trade-offs between fast processing and effective memory management.

    If we keep more messages in memory, the processing is faster. However the memory consumption will be very high. On the contrary, if messages are kept on the disk then processing will become slow.

    Conclusion

    We have seen in this blog how store, temp and memory usage work in ActiveMQ. % of store and temp usage cannot be configured per destination while % of memory usage can be because of  cursorMemoryHighWaterMark.

    Hope you found this information useful. The examples given here are for explanation purposes only and not meant to be production ready. You will need to do proper capacity planning and determine your broker topology for optimal configuration. Feel free to reach out if any comments!

    References