Как настроить G1GC на меньшую площадь памяти?

Question

Я экспериментировал с G1GC с Java 8 (Oracle JVM) в одном из моих проектов. Мои GC флаги эффективно:

-Xms64m 
-Xmx1024m 
-XX:+UseG1GC 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-Xloggc:/tmp/gc.log 
-XX:+PrintAdaptiveSizePolicy 

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

[G1Ergonomics (Heap Sizing) attempt heap expansion, reason: recent GC overhead higher than threshold after GC, recent GC overhead: 10.17 %, threshold: 10.00 %, uncommitted: 811597824 bytes, calculated expansion amount: 162319564 bytes (20.00 %)] 

Эффективно мое приложение генерирует много мусора, и поэтому доля времени, потраченного в GC выше, чем 10%, и поэтому эргономика G1 увеличивают размер кучи.

---

С параллельного коллектором этого порог может быть настроен с -XX:GCTimeRatio (пропускной способностью цели), но от того, что я могу видеть в docs нет никакого эквивалента флага для G1.

Для параллельного коллектора Java SE предоставляет два параметра настройки сбора мусора, которые основаны на достижении определенного поведения приложения: максимальная цель времени паузы и целевая пропускная способность приложения; см. раздел «Параллельный коллектор». (Эти два варианта недоступны в других сборниках.) Обратите внимание, что это поведение не всегда может быть выполнено.

Мой вопрос заключается в том, чтобы опустить максимальный размер кучи, как я могу настроить G1GC на меньшую площадь памяти?

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

---

Это возможно боян этого вопроса: Which JVM Flag sets the GC overhead threshold mentioned in the G1Ergonomics log?, но это выглядит как неправильный ответ был принят. (Или, возможно, это было правильно только для более старой версии JVM.)

Answer 1

При дальнейших исследованиях кажется, что эргономика G1 уважает -XX:GCTimeRatio, несмотря на то, что говорят документы.

Answer 2

Обзор:

• В this Oracle article (1) вы можете найти наиболее важные флаги для G1 (inlcuding -XX:MaxGCPauseMillis).

• This bug report указывает, что флаг GCTimeRatio также используется в G1.

• См. Также this related question & answer (2).

• Я предполагаю, что вы должны быть в состоянии решить эту проблему, установив -XX:MaxGCPauseMillis на более высокое значение, или если вы знаете, что ваше приложение создает много (молодой) мусора, вы можете играть с настройками о размере молодого поколения. EDIT: ОК, будьте очень осторожны в этом, (1): * Young Generation Size *: Избегайте явного задания размера молодого поколения с помощью опции -Xmn или любого другого связанного параметра, такого как -XX: NewRatio. Фиксирование размера молодого поколения переопределяет цель цели паузы.

---

(1)

Важные значения по умолчанию:

У G1 ГХ представляет собой адаптивный сборщик мусора со значениями по умолчанию, которые позволяют ему эффективно работать без изменений. Вот список важных параметров и их значений по умолчанию. Этот список относится к последней виртуальной машине Java HotSpot, сборке 24. Вы можете адаптировать и настроить GC G1 к потребностям производительности приложений, введя следующие параметры с измененными параметрами в командной строке JVM.

• -XX: G1HeapRegionSize = п

Устанавливает размер области G1. Значение будет иметь мощность 2 и может варьироваться от 1 МБ до 32 МБ. Цель состоит в том, чтобы иметь около 2048 регионов на основе минимального размера кучи Java.

• -XX: MaxGCPauseMillis = 200

Устанавливает целевое значение для требуемого максимального времени паузы. Значение по умолчанию - 200 миллисекунд. Указанное значение не адаптируется к размеру вашей кучи.

• -XX: G1NewSizePercent = 5

Устанавливает процент кучи для использования в качестве минимума для молодого поколения размера. Значение по умолчанию составляет 5 процентов от вашей кучи Java. Это экспериментальный флаг. См. «Как разблокировать экспериментальные флаги VM» для примера. Этот параметр заменяет параметр -XX: DefaultMinNewGenPercent. Этот параметр не доступен в Java HotSpot VM, построить 23.

• -XX: G1MaxNewSizePercent = 60

Устанавливает процент от размера кучи, чтобы использовать в качестве максимума для молодого поколения размера. Значение по умолчанию составляет 60 процентов от вашей кучи Java. Это экспериментальный флаг. См. «Как разблокировать экспериментальные флаги VM» для примера. Этот параметр заменяет параметр -XX: DefaultMaxNewGenPercent. Эта настройка не доступна на Java HotSpot VM, построить 23.

• -XX: ParallelGCThreads = N

Устанавливает значение рабочих потоков STW. Устанавливает значение n в число логических процессоров. Значение n совпадает с числом логических процессоров до значения 8.

Если имеется более восьми логических процессоров, устанавливается значение n примерно 5/8 логических процессоров. Это работает в большинстве случаев, за исключением больших систем SPARC, где значение n может составлять приблизительно 5/16 от логических процессоров.

• -XX: ConcGCThreads = п

Устанавливает количество параллельных потоков маркировки. Устанавливает n примерно на 1/4 числа параллельных потоков сбора мусора (ParallelGCThreads).

• -XX: InitiatingHeapOccupancyPercent = 45

Устанавливает порог кучи заполненности Java, которое запускает цикл маркировки. Заселение по умолчанию составляет 45 процентов всей кучи Java.

• -XX: G1MixedGCLiveThresholdPercent = 65

Установка порога вместимости старая область должна быть включена в смешанном цикле сбора мусора. Заселение по умолчанию составляет 65 процентов. Это экспериментальный флаг. См. «Как разблокировать экспериментальные флаги VM» для примера. Этот параметр заменяет параметр -XX: G1OldCSetRegionLiveThresholdPercent. Этот параметр не доступен в Java HotSpot VM, построить 23.

• -XX: G1HeapWastePercent = 10

Устанавливает процент кучи, которую вы готовы тратить. VM Java HotSpot не инициирует смешанный цикл сбора мусора, когда процент рекуперации меньше, чем процент отходов кучи. Значение по умолчанию - 10 процентов. Этот параметр не доступен в Java HotSpot VM, построить 23.

• -XX: G1MixedGCCountTarget = 8

Устанавливает целевое количество смешанных коллекций мусора после маркировки цикла собирать старые районы с не более G1MixedGCLIveThresholdВыбор данных в реальном времени. По умолчанию используется 8 смешанных сборок мусора. Цель смешанных коллекций - находиться в пределах этого целевого номера. Этот параметр не доступен в Java HotSpot VM, построить 23.

• -XX: G1OldCSetRegionThresholdPercent = 10

Устанавливает верхний предел числа старых районов, которые будут собраны во время цикла сбора смешанного мусора , Значение по умолчанию - 10 процентов кучи Java. Этот параметр не доступен в Java HotSpot VM, построить 23.

• -XX: G1ReservePercent = 10

Устанавливает процент резервной памяти, чтобы сохранить свободный таким образом, чтобы уменьшить риск-космос переполняется. Значение по умолчанию - 10 процентов. Когда вы увеличиваете или уменьшаете процент, не забудьте настроить общую кучу Java на ту же сумму. Этот параметр не доступен в Java HotSpot VM, построить 23.

---

(2)

Я думаю, что recent GC overhead higher than threshold гонит решения G1 в.Вы можете расслабить его, установив -XX:GCTimeRatio=4, что позволит ему занять до 20% циклов процессора относительно времени приложения для GCing вместо 10%.

Если это слишком много, вы должны либо

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

• расслабить паузу цели времени, так что приходится собирать реже