Постоянная генерация: емкость значения по умолчанию становится фиксированной или будет расти по мере необходимости?

Question

мы отмечаем, что у нашего клиента, работающего под управлением Solaris 10, постоянный GC увеличивается с 50% до 97% емкости.Эта JVM использовала значение по умолчанию «permgen» (мы НЕ передавали какой-либо пользовательский флаг Permgen в JVM).

Вместо того, чтобы работать на 97% пространства permgen в производстве, следует ли нам установить более высокое значение PermGen?

PS: мы используем JDK 1.6.0_23 на солярисе 10.

ОБНОВЛЕНИЕ Должны ли мы думать, что в ближайшее время может произойти ошибка OutOfMemoryError?ИЛИ возможно ли, что JVM увеличит емкость, чтобы использование упало ниже 97%?

Answer 1

Используемое пространство PermGen может со временем увеличиваться до определенных утечек / ошибок в памяти в коде приложения или в используемых вами библиотеках.

Например, мы часто видим проблемы при запускеwebapp в Apache Tomcat, который использует Spring и log4j, если экземпляр webapp загружается слишком много раз, очевидно, у log4j есть некоторые проблемы, из-за которых он не выгружает некоторые классы из загрузчика классов должным образом.утечки, которые приводят к увеличению пространства PermGen с течением времени, как обычные утечки памяти.

Answer 2

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

Answer 3

Я считаю, что JVM будет использовать ту же стратегию для расширения кучи permgen, что и для обычной кучи.

• Размер кучи permgen начинается с настраиваемого начального размера
• Если отношение использованной кучи пермгена к размеру кучи пермгена больше заданного значения после сбора пермгена, оно будет расширено.
• Размер кучи permgen может увеличиться до настраиваемого максимального размера

Теперь, если куча permgen заполнена на 97% после GC, весьма вероятно, что permgen уже был расширен до максимального настроенного размера (по умолчанию в вашем случае).

Невозможно сказать, где неизбежен ООМ. (Это зависит от того, как ваше приложение ведет себя и что заставляет его увеличивать использование permgen.) Однако было бы благоразумно до:

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

Answer 4

Мы замечаем, что у нашего клиента, работающего под управлением Solaris 10, постоянный GC увеличивается с 50% до 97% емкости.

Произошло ли существенное изменение кода в приложении вашего клиента дозаметили всплеск в Перми?Или это всегда было так (от 50% до 97%)?

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

Одно можно сказать наверняка, что работа на 97% слишком близка к максимальной для комфорта, и вам придется играть с максимальнойпараметры perm gen (и, как следствие, с другими параметрами кучи ... скорее всего.)

Эта JVM использовала значение по умолчанию "permgen" (мы НЕ передавали какой-либо пользовательский флаг Permgen вJVM).

Не очень хорошая идея.Вы должны (прочитайте должны) всегда характеризовать ваши (или ваши клиенты) приложения перед развертыванием.Либо ваши клиенты должны сообщить вам, какие параметры им нужны, либо ваша команда должна определить их во время UAT и циклов тестирования системы (при условии, что у вас есть наглядность для них; см. Выше.)

Должны ли мы думать, что в ближайшее время, это может сделать OutOfMemoryError?

Это не неизбежно, но это возможно (особенно если приложение еще не подверглось максимально возможной загрузке.) Это также возможно, еслиспайк - недавнее явление.В этом случае, скорее всего, из-за изменения кода или ранее неизвестного состояния из-за других факторов (исправление в ОС, в контейнере, изменение трафика клиента, изменение в БД и т. Д.)

Вместо того, чтобы использовать в производственном пространстве 97% permgen, следует ли нам устанавливать более высокое значение PermGen?

IMO, да.Если вы (или ваш клиент) можете охарактеризовать или оценить требования к памяти приложения (как перманентной, так и кучи) (а также текущий и возможный будущий трафик), вы должны на всякий случай предоставить себе маржу в 10% -20%.Все, что меньше, это просто игра с огнем.Все, скорее всего, будет расточительным.

Память может быть дешевой, но производительность и стабильность приложений - нет;)

Если вы не используете visualgc, вам следует.Это хороший инструмент для визуальной проверки того, что происходит с различными сегментами в вашей памяти JVM.Существует также visualvm, который является более мощным и универсальным, однако представление показаний пользовательского интерфейса visualgc особенно подходит для этой задачи.

PS: мы используем JDK 1.6.0_23 на Solaris 10.

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

Answer 5

Ваши рассуждения немного неясны.

Если вы предвидите неудачу, почему бы не предпринять оборонительный подход и сразу же увеличить -XX:MaxPermSize?

Answer 6

Существует максимальный размер PermGen, и вы получаете OutOfMemoryError, когда этот si достиг.Однако, если вы заполнены на 97%, это не означает, что вы достигли максимума, просто 97% пространства, выделенного в это время.(Еще на 3% придется увеличить пространство, если сможет)