Слишком много основных сборок мусора: добавить пространство кучи или добавить другую виртуальную машину?

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

У нас есть приложение, работающее в WebLogic/JRockit в управляемом кластере.

AppDynamics отслеживает это приложение, и оно показывает, что крупные сборки мусора происходят часто (в среднем каждые 1-2 минуты!!!). Когда запускается большая сборка мусора, она восстанавливает пространство, и нижний диапазон использования кучи является достаточно низким, даже после того, как система некоторое время работала (недели / месяцы). Кроме того, мы запустили обнаружение утечек в коллекциях AppDynamics и не обнаружили утечек. (Мы не смогли запустить пользовательский мониторинг, потому что он не поддерживается JRockit.) Но в целом кажется очевидным, что серьезных утечек нет, просто система требует больше ресурсов, чем в настоящее время.

У нас есть две непроизводственные среды, в которых также работает это приложение с уменьшенными ресурсами и пониженной нагрузкой (dev и test). Среда тестирования имеет 2/3 числа виртуальных машин и 1/2 кучи на виртуальную машину. Мы провели несколько нагрузочных тестов в этой среде, но результаты оказались не очень полезными. Хотя мы можем воссоздать количество пользователей, использующих автоматизированные сценарии, данные в нашей тестовой среде сильно отличаются - запросы возвращают данные на порядок меньше и т. Д. (Создание лучшей среды нагрузочного тестирования, безусловно, есть в списке задач, но вряд ли на самом деле произойдет в ближайшее время по причинам бюрократии.) Даже со всем, что мы могли на это бросить, тестовая среда не сломала пот.

Два варианта, а) Добавить больше кучи. Кажется, это наверняка поможет, но для этого потребуется много бумажной работы (потребуется добавить больше памяти на физические серверы, что означает перезапуск сервера с использованием множества других приложений и т. Д.). Кроме того, я понятия не имею, сколько еще памяти можно добавить, и мы не можем просто "проверить в prod". Б) Добавьте еще одну ВМ (или две) для этого приложения. Это было бы довольно просто, у нас есть место на другом физическом сервере, поэтому мы могли бы сделать это довольно быстро. Но я не уверен, что это сильно поможет, и если это не поможет, то вернуться к варианту А позже будет еще сложнее.

Конкретные вопросы: 1) Является ли один из вышеуказанных вариантов явно лучше (и почему)? 2) Если ни один из них явно не лучше, какие тесты и т. Д. Я бы сделал, чтобы решить, что лучше? 3) Как мне решить и обосновать, сколько еще ресурсов добавить (куча или виртуальные машины)? (Бонусные баллы здесь, если это касается инструментов, которые у нас уже есть.)

Обновления:

  • 3 JVM в кластере, каждая JVM находится на отдельной виртуальной машине.
  • Они находятся за балансировщиком нагрузки Apache, каждый сервер получает примерно равную нагрузку.
  • Каждая JVM имеет кучу 1 ГБ.
  • Нет FMW.

2 ответа

Решение

В итоге мы выполнили оба действия (добавив больше пространства кучи от 1 до 1,5 ГБ и добавив больше управляемых узлов от 3 до 5).

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

Добавление большего количества узлов вызвало лишь незначительное улучшение, но трудно определить, действительно ли это было не очень полезно, или просто не было много места для улучшения после увеличения кучи.

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

Благодаря оптимизации кода и / или даже более точной настройке кучи памяти в зависимости от размера и жизненного цикла создаваемых объектов (что, в свою очередь, зависит от конкретной используемой вами JVM), не так много возможностей для улучшения, кроме добавления большего количества управляемые узлы в вашем домене.

Это может быть легко достигнуто с помощью инструмента, уже присутствующего в каждой установке WebLogic, а именно WLST.

Хорошо документировано, как создавать управляемые узлы и их соответствующие менеджеры узлов в существующем кластере с использованием WLST.

Другие вопросы по тегам