Как мы можем улучшить производительность GC для системы с низкой задержкой

Question

Наша бэкэнд-система java работает с tomcat и jdk1.8, максимальный размер jvm составляет 24 г, задержка системы становится большой, а загрузка процессора высока, после того, как мы проанализировали журналы GC, мы обнаружили, что GC-пауза длинная, к ней прикреплены некоторые снимкив GCViewer.Как мы можем улучшить производительность GC?

Answer 1

Не зная вашего приложения, вот несколько общих соображений:

• В вашем приложении, по-видимому, содержится большое количество долгоживущих объектов (только 9 ГБ из заемного поколения получено, осталось 15 ГБ), которые вызывают ваши проблемы: в то время как скорость выделения определяет частоту пауз ГХ, именно количество живых объектов (которые не могут быть освобождены ГХ) определяет длину пауз ГХ.
• Одной из возможных причин может бытьчто ваше приложение в некоторой степени действует как база данных в памяти.То есть объекты не нужны все время, но не записываются в базу данных для обеспечения быстрого доступа к ним в памяти.В этом случае вы должны хранить их вне кучи (в памяти, не управляемой GC) или использовать базу данных в памяти, например, Redis.Таким образом, они будут доступны с низкой задержкой, но не будут рассматриваться GC, поскольку они все равно не будут восстановлены.
• Другое возможное решение может заключаться в настройке параметров GC: вы можете переключиться на G1увеличьте размер своего молодого поколения или увеличьте порог продвижения по службе;или сочетание тех.Увеличение молодого поколения и сокращение продвижения по службе может привести к гораздо меньшему росту поколения и, следовательно, к уменьшению количества крупных коллекций.Переключение на коллектор G1 даст вам преимущество в том, что этот коллектор может рассматривать только некоторые выжившие регионы и может оставлять регионы с одними бессмертными объектами.

Answer 2

Давным-давно я написал руководство по этой теме.Это все еще очень актуально.

Самое важное для сборщика мусора CMS при определении размеров.Кажется, что и ваше молодое, и старое пространство слишком мало.

Старое пространство должно быть размером вашего живого набора (~ размер кучи после полного GC), умноженным на определенный коэффициент.Фактор должен быть найден эмпирически, 1.5 - хорошая отправная точка.

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

-XX:InitiatingHeapOccupancyPercent=n и -XX:+UseCMSInitiatingOccupancyOnly рекомендуются для обеспечения своевременного запуска параллельного цикла.В некоторых ситуациях -XX:CMSTriggerInterval=p также полезно.