Сборщик мусора G1: Пермский ген заполняется неопределенно долго, пока не будет выполнен полный GC

Ответ 1

Причины роста Perm Gen

• Множество классов, особенно JSP.
• Множество статических переменных.
• Существует утечка загрузчика классов.

Для тех, кто не знает, вот простой способ подумать о том, как PremGen заполняется. У молодого генерала не хватает времени, чтобы все закончилось, и поэтому они переместились в пространство старого поколения. Пермский Ген имеет классы для объектов в Молодом и Ветхом Генеале. Когда объекты в Молодом или Старом Генеале собраны, а класс больше не ссылается, он получает "выгружен" из Пермского Генерала. Если Молодые и Молодые Старый генерал не получает GC'd, а затем и Пермский генерал, и как только он заполняется, ему нужен Full Stop-the-world GC. Для получения дополнительной информации см. Представление постоянного поколения.

Переход на CMS

Я знаю, что вы используете G1, но если вы переключитесь на сборщик низкоуровневых паролей Concurrent Mark Sweep (CMS) -XX:+UseConcMarkSweepGC, попробуйте включить сбор классов и коллекцию постоянного поколения, добавив -XX:+CMSClassUnloadingEnabled.

Скрытый Gotcha

Если вы используете JBoss, у RMI/DGC установлен gcInterval на 1 мин. Подсистема RMI заставляет полную сборку мусора раз в минуту. Это, в свою очередь, стимулирует продвижение, а не позволяет собирать его в Молодом поколении.

Вы должны изменить это, по крайней мере, на 1 час, если не 24 часа, чтобы GC выполнил правильные коллекции.

-Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

Список всех опций JVM

Чтобы просмотреть все параметры, запустите это из строки cmd.

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

Если вы хотите увидеть, что использует JBoss, вам нужно добавить следующее к вашему standalone.xml. Вы получите список всех параметров JVM и того, для чего он установлен. ПРИМЕЧАНИЕ. Это должно быть в JVM, на который вы хотите посмотреть, чтобы использовать его. Если вы запустите его внешним, вы не увидите, что происходит в JVM, на котором работает JBoss.

set "JAVA_OPTS= -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal %JAVA_OPTS%"

Существует ярлык для использования, когда нас интересуют только измененные флаги.

-XX:+PrintcommandLineFlags

Диагностика

Используйте jmap, чтобы определить, какие классы потребляют пространство постоянного поколения. На выходе будет отображаться

• загрузчик классов
• # классов
• байт
• родительский загрузчик
• живой/мертвый
• типа

• Итоги

  jmap -permstat JBOSS_PID  >& permstat.out
  

Параметры JVM

Эти настройки работали для меня, но в зависимости от того, как ваша система настроена и что делает ваше приложение, определит, подходят ли они для вас.

• -XX:SurvivorRatio=8 - Устанавливает отношение пространства выживших к 1: 8, в результате чего большие пространства для оставшихся в живых (чем меньше отношение, тем больше пространство). SurvivorRatio - это размер пространства Эдена по сравнению с одним оставшимся в живых. Большие оставшиеся в живых пространства позволяют коротким объектам более длительный период времени умирать в молодости.

• -XX:TargetSurvivorRatio=90 - Позволяет заняться 90% оставшихся в живых, вместо 50% по умолчанию, что позволяет лучше использовать память памяти оставшегося в живых.

• -XX:MaxTenuringThreshold=31 - Чтобы предотвратить преждевременное продвижение от молодого поколения к поколению. Позволяет короткоживущим объектам более длительный период времени умирать в молодом поколении (и, следовательно, избегать продвижения по службе). Следствием этого параметра является то, что незначительные GC-времена могут увеличиваться из-за дополнительных объектов для копирования. Это значение и размеры пространства для оставшихся в живых могут нуждаться в корректировке, чтобы сбалансировать накладные расходы на копирование между оставшимися в живых пространствами и объектами владения, которые будут жить в течение длительного времени. Настройки по умолчанию для CMS: SurvivorRatio = 1024 и MaxTenuringThreshold = 0, которые заставляют всех оставшихся в живых убирать. Это может оказать большое давление на единую параллельную нить, собирающую поколение. Примечание: при использовании с -XX: + UseBiasedLocking этот параметр должен быть равен 15.

• -XX:NewSize=768m - позволяет определять начальные размеры молодого поколения

• -XX:MaxNewSize=768m - разрешить спецификацию максимальных размеров молодого поколения

Ниже приведен более подробный список JVM options.

Ответ 2

Является ли это ожидаемым поведением с G1?

Я не считаю это удивительным. Основополагающим предположением является то, что материал, помещенный в пергень, почти никогда не становится мусором. Таким образом, вы ожидаете, что пермген GC будет "последним средством"; то есть что-то, что JVM будет делать только в том случае, если его принуждают к полному GC. (ОК, этот аргумент нигде не близок к доказательству... но он соответствует следующему.)

Я видел много доказательств того, что у других коллекционеров одинаковое поведение; например.

• сбор мусора в пермг принимает несколько полных GC
• Что происходит с java GC? Пространство PermGen заполняется?

Я нашел еще одну публикацию в Интернете о том, что кто-то спрашивает что-то очень похожее и говорит, что G1 должен выполнять инкрементные коллекции в Перми, но ответа не было...

Я думаю, что нашел тот же пост. Но кто-то считает, что это должно быть возможно, не очень поучительно.

Есть ли что-то, что я могу улучшить/исправить в наших параметрах запуска?

Я сомневаюсь. Я понимаю, что это присуще стратегии GCG.

Я предлагаю вам либо отследить, либо исправить то, что использует столько перменов, в первую очередь... или переключиться на Java 8, в котором больше нет кучи permgen: см. Исключение PermGen в JDK 8

В то время как утечка пергентов является одним из возможных объяснений, есть другие; например.

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

Ответ 3

Сначала я попытался бы найти основную причину, по которой PermGen становится больше, до случайного использования JVM-параметров.

• Вы можете включить ведение журнала загрузки классов (-verbose: class, -XX: + TraceClassLoading -XX: + TraceClassUnloading,...) и вывести вывод
• В тестовой среде вы можете попробовать контролировать (над JMX), когда классы загружаются (java.lang: type = ClassLoading LoadedClassCount). Это может помочь вам узнать, какая часть вашего приложения несет ответственность.
• Вы также можете попробовать перечислить все классы с помощью инструментов JVM (извините, но я по-прежнему в основном использую jrockit и там вы будете делать это с помощью jrcmd. Hope Oracle перенес эти полезные функции в Hotspot...)

В общем, узнайте, что генерирует так много классов, а затем подумайте, как уменьшить это/настроить gc.

Cheers, Димо

Ответ 4

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

Там этот поток на форумах JBoss, которые проходят через пару таких диагностированных случаев и как они были исправлены. этот ответ и в этой статье также обсуждается проблема. В этой статье упоминается, возможно, самый простой тест, который вы можете сделать:

Симптом

Это произойдет только при повторном развертывании вашего приложения без перезапуск сервера приложений. Серия JBoss 4.0.x пострадала от такой утечки загрузчика класса. В результате я не смог перераспределить наше приложение более двух раз, прежде чем JVM закончится Память и авария PermGen.

Решение

Чтобы определить такую ​​утечку, разверните приложение и затем выполните полный дамп кучи (обязательно запустите GC перед этим). Затем проверьте, вы можете найти любой из ваших объектов приложения в дампе. Если так, следуйте их ссылкам на их корень, и вы найдете причину ваша утечка загрузчика. В случае JBoss 4.0 единственным решением было для перезапуска для каждого повторного развертывания.

Это то, что я постараюсь первым, ЕСЛИ вы думаете, что перераспределение может быть связано. Это сообщение в блоге является более ранним, делая то же самое, но также обсуждая детали. Основываясь на публикации, может быть, что вы на самом деле не перераспределяете что-либо, но перджен просто заполняется сам по себе. В этом случае рассмотрение классов + все, что добавлено в пермг, может быть способом (как уже упоминалось в предыдущем ответе).

Если это не даст больше понимания, мой следующий шаг будет проверять plumbr tool. У них есть своего рода гарантия на обнаружение утечки для вас.

Ответ 5

Вы должны запустить server.bat с командой java с помощью -verbose: gc