JVM G1GC смешанный gc не собирает много старых регионов

Мой сервер использует 1.8.0_92 в CentOS 6.7, параметр GC - "-Xms16g -Xmx16g -XX: + UseG1GC". Поэтому значение InitiatingHeapOccupancyPercent по умолчанию равно 45, значение G1HeapWastePercent равно 5, а значение G1MixedGCLiveThresholdPercent равно 85. Мой смешанный GC для сервера начинается с 7,2 ГБ, но он очищается все меньше и меньше, в конце концов старый gen остается большим, чем 7,2 ГБ, поэтому он всегда пытается выполнить одновременную метку. Наконец все кучи исчерпаны и полный GC произошел. После полной GC, старый используемый ген под 500 МБ.

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

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

Ниже в журнале приведен результат изменения InitiatingHeapOccupancyPercent до 15 (начать параллельную отметку на 2,4 ГБ) для ускорения.

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

Я использовал салат в качестве моего клиента Redis, и он использует отслеживание с помощью LatencyUtils. Это делает LatencyStats (который содержит несколько long[] с почти 3000 элементами) слабыми ссылками на экземпляры каждые 10 минут (Сброс задержек после публикации по умолчанию равен true, https://github.com/mp911de/lettuce/wiki/Command-Latency-Metrics). Так что после долгого времени он будет делать много слабых ссылок на LatencyStats.

В настоящее время мне не нужно отслеживать с салата, так что просто отключите его, и он больше не имеет полного GC. Но не уверен, почему смешанный gc не очищает их.

Ответы

Ответ 1

ну, вы не упомянули все аргументы, которые вы задали, но

Вы могли бы попытаться установить

-XX:+ScavengeBeforeFullGC

и вам также следует подумать о жизненном цикле вашего Object. как долго ваши приложения Object живой и какой размер являются Object s.

подумайте об этом и взгляните на следующие аргументы

-XX:NewRatio=n              old/new ration (default 2)
-XX:SurvivorRatio=n         eden/survivor ratio (default 8)
-XX:MaxTenuringThreshold=n  number of times, objects are moved from survivor one to survivor two and vice versa before objects are moved to old-gen (default 15)

со значениями по умолчанию Xms и Xmx установлены в 32gb → old gen = 16gb и new gen 16gb → eden 14gb → оставшиеся в живых 2gb (есть два, каждый из которых имеет размер 1gb)

eden содержит все Object, которые создаются new Object.

один оставшийся в живых (оставшийся в живых) всегда пуст. другие (из-оставшегося в живых) содержит Object который пережил незначительный GC

оставшийся в живых Object из Эдема и из оставшегося в живых переходит в оставшийся в живых в несовершеннолетнем

если стандартный размер 1 ГБ этой 'конфигурации по умолчанию' превышает, Object переходит в old-gen

если оно не превышает, после 15 -XX:MaxTenuringThreshold gc (-XX:MaxTenuringThreshold умолчанию -XX:MaxTenuringThreshold) Object переходит в old-gen

изменяя эти значения, всегда имейте в виду, old-gen должен быть таким же большим или большим, как new-gen, потому что gc может заставить весь new-gen перейти в old-gen

редактировать

была бы полезна временная шкала вашего первого изображения "old gen: used"

имейте в виду, что нет необходимости делать полный gc, пока старый gen не превысит - полный gc заставляет весь "мир" останавливаться на определенный период времени

в этом конкретном случае, я бы сказал, что вы могли бы

уменьшить -Xms и -Xmx до 8 -Xmx
установить/уменьшить -XX:SurvivorRatio значение -XX:SurvivorRatio до 2
установить/увеличить -XX:MaxTenuringThreshold до 50

и вы получите старый и новый ген, каждый размером 4 ГБ,

Eden размером 2 ГБ,

два выживших, каждый размером 1Гб,

и примерно 50 второстепенных, прежде чем Object войдет в старое поколение