У нас пока нет ошибок приложения, но наши инструменты мониторинга показывают, что наше приложение работает на пределе своих ресурсов. Должны ли мы сначала добавить больше кучи или добавить дополнительную виртуальную машину?
У нас есть приложение, работающее на WebLogic / JRockit в управляемом кластере.
У нас есть AppDynamics, отслеживающий это приложение, и он показывает, что основная сборка мусора происходит часто (в среднем каждые 1-2 минуты !!!). Когда выполняется крупная сборка мусора, она восстанавливает пространство, и нижний диапазон использования кучи является достаточно низким, даже после того, как система проработала некоторое время (недели / месяцы). Кроме того, мы запустили обнаружение утечек коллекций AppDynamics в производственной среде и не обнаружили утечек. (Мы не могли запустить настраиваемый мониторинг, потому что он не поддерживается JRockit.) Но в целом кажется очевидным, что серьезных утечек нет, просто система требует больше ресурсов, чем имеет в настоящее время.
У нас есть две непроизводственные среды, в которых также работает это приложение с сокращенными ресурсами и уменьшенной нагрузкой (разработка и тестирование). В тестовой среде 2/3 количества виртуальных машин и 1/2 кучи на виртуальную машину. Мы провели несколько нагрузочных тестов в этой среде, но результаты не очень помогли. Хотя мы можем воссоздать количество пользователей с помощью автоматических скриптов, данные в нашей тестовой среде сильно отличаются - запросы возвращают на порядки меньше данных и т. Д. (Создание лучшей среды нагрузочного тестирования, безусловно, входит в список дел, но маловероятно на самом деле произойдет в ближайшее время по причинам бюрократии.) Даже со всем, что мы могли бросить на это, тестовая среда не вспотела.
Два варианта: А) Добавить еще кучу. Кажется, что это наверняка поможет, но для этого потребуется много документов (потребуется добавить больше памяти к физическим серверам, что означает перезапуск сервера с участием множества других приложений и т. Д.). Кроме того, я понятия не имею, сколько еще памяти нужно добавить, и мы не можем просто «протестировать в продукте». Б) Добавьте еще одну виртуальную машину (или две) для этого приложения. Это было бы довольно просто, у нас есть место на другом физическом сервере, поэтому мы можем сделать это довольно быстро. Но я не уверен, что это поможет, и если это не поможет, вернуться к варианту А позже будет еще сложнее.
Конкретные вопросы: 1) Очевидно ли, что один из вышеперечисленных вариантов лучше (и почему)? 2) Если ни один из них явно не лучше, какие тесты и т. Д. Я бы сделал, чтобы решить, что лучше? 3) Как мне решить и обосновать, сколько еще ресурсов нужно добавить (кучу или виртуальные машины)? (Бонусные баллы здесь, если это касается инструментов, которые у нас уже есть.)
Обновления:
В итоге мы сделали и то, и другое (добавили больше места в куче с 1 ГБ до 1,5 ГБ и добавили больше управляемых узлов с 3 до 5).
Размер кучи был увеличен примерно за час до добавления новых узлов, и самого по себе этого было достаточно, чтобы значительно сократить количество сборок мусора и время, затрачиваемое на сборку мусора.
Добавление дополнительных узлов вызвало лишь незначительное улучшение, но трудно определить, действительно ли это было не очень полезно, или просто не было много возможностей для улучшения после увеличения кучи.
Предполагая, что приложение было тщательно профилировано и никаких утечек памяти не существует (как кажется), вы должны исходить из того, что объекты, создаваемые в куче, происходят из-за нормальной активности приложения.
Избегая оптимизации кода и / или даже более точной настройки кучи памяти в зависимости от размера и жизненного цикла создаваемых объектов (который, в свою очередь, зависит от конкретной используемой JVM), мало возможностей для улучшения, кроме добавления большего количества управляемые узлы в ваш домен.
Этого легко достичь с помощью инструмента, уже присутствующего в каждой установке WebLogic, а именно WLST.
Хорошо задокументировано, как с помощью WLST создавать управляемые узлы и соответствующие им диспетчеры узлов в существующем кластере.