Пермгенское пространство: идеальное поведение для достижения
Я пытаюсь проанализировать / профилировать основное приложение JAVA.
Я использую JConsole с Eclipse MAT.
Я наблюдал следующее на графиках Perm-Gen (данные, записанные в течение 1 часа на компьютере с Windows XP):
Код кэша:
- В начале записи: 7 МБ
- Через 1 час: 10,5 МБ
- График выглядит следующим образом: наклонная линия слегка поднимается с интервалами.
Пул памяти Perm-Gen(Shared-rw):
- В начале записи: 7 МБ
- Через 1 час: 7 МБ
- График выглядит так: параллельно оси X
Пул памяти Perm-Gen(Shared-r0):
- В начале записи: 5,5 МБ
- Через 1 час: 5,5 МБ
- График выглядит так: параллельно оси X
Пул памяти:
- В начале записи: 21 МБ
- Через 1 час: 22,5 МБ
- График выглядит следующим образом: наклонная линия слегка поднимается / опускается с интервалами.
Мой вопрос
- Что можно вывести из такого поведения пермско-женского пространства для каждой из вышеперечисленных категорий?
- Каким должно быть идеальное поведение для поиска каждой из вышеперечисленных категорий?
Идеальное поведение здесь относится к состоянию, которое представляет:
- Приложение работает в лучшем случае.
- Приложение не имеет проблем с памятью.
- Никаких улучшений в коде для улучшения использования ресурсов не требуется.
Вышеуказанный вопрос также применим для анализа пространства кучи.
Ниже приведены дополнительные разъяснения:
Это правда, что профилирование должно быть сделано в той же среде, что и производство. Но было бы очень полезно, если бы я мог понять, какова реальная цель здесь. На данный момент я пытаюсь выучить то же самое. Тогда в будущем я постараюсь сделать это на производстве.
Кроме того, я пытаюсь сравнить две базы кода (одна рефакторированная и одна старая). Я хочу знать степень преимуществ, которые достигаются путем рефакторинга (как количественные данные). Я думаю, что если я записываю результаты на той же платформе, сравнение будет справедливо (независимо от производства или разработки).
ОБНОВЛЕНИЕ 1:
- Далее я запускал приложение более 8 часов подряд.
- Я использовал GCViewer:1.31 для получения информации о GC.
- Я прилагаю данные, собранные из GCViewer.
- Я заметил, что каждые 30 секунд происходит одно событие FULL GC. Это делает вывод, что множество объектов
log-living
, - Мне нужна дополнительная информация. Я действительно не уверен, как правильно и полностью интерпретировать эти детали.
Пожалуйста, посмотрите на приложение. Пожалуйста, предоставьте информацию.
1 ответ
Пара предложений:
1) Дитч JConsole. VisualVM включен в JDK и превосходит его во всех отношениях (и включает режим моста, так что вы даже можете использовать старые плагины, если это все, что удерживает вас на JConsole).
2) Включите регистрацию GC. Вам нужны как минимум эти флаги:
-Xloggc: (для более полного ведения журнала GC) -XX:+PrintGCDetails (для более подробного вывода) -XX:+PrintTenuringDistribution (отображает пороги владения, принятые JVM)
Найдите инструмент для анализа журналов - вам нужно обратить внимание на рабочий набор объектов, а также на PermGen, даже если последний является вашей главной задачей. GCViewer бесплатен, или есть коммерческие инструменты (полное раскрытие - я работаю на jClarity, которая производит инструмент Censum для этой цели).
3) Вам нужно бежать намного дольше, чем 1 час. Многие приложения не стабилизируются в течение долгого времени.
4) Снова глядя на ваши номера, это не выглядит чем-то необычным / проблемой. Почему вы настраиваете этот бит JVM? Какой аспект системы показал, что это серьезная проблема, и над ней нужно работать? Как вы это определили и как проявляется эта проблема?