Для принципов GC и практики настройки производительности этой статьи достаточно!

Java JVM

предисловие

В этой статье представлены основные принципы и теории GC, идеи и методы настройки GC, основанные на Hotspot jdk1.8.После изучения вы узнаете, как устранять неполадки и решать проблемы GC в производственной системе.

текст

Основное содержание этой статьи следующее:

  • Основные принципы GC, включая цели настройки, классификацию событий GC, стратегию распределения памяти JVM, анализ журнала GC и т. д.
  • Принцип и настройка CMS.
  • Принцип G1 и настройка
  • Устранение неполадок ГХ и решения

1. Основные принципы ГК

1.1 Цели настройки сборщика мусора

Настройка GC Java-программ в большинстве случаев преследует две цели:

  • Ответная реакция: Скорость отклика означает, насколько быстро программа или система отвечает на запрос.

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

  • пропускная способность: пропускная способность ориентирована на максимальную нагрузку системы приложений в определенный период времени.

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

При настройке сборщика мусора время паузы приложения, вызванное сборщиком мусора, влияет на скорость отклика системы, а использование ЦП потоками обработки сборщика мусора влияет на пропускную способность системы.

1.2 Алгоритм сбора поколений GC

Современные сборщики мусора в основном используют алгоритмы сборки поколений.Основная идея состоит в том, чтобы логически разделить память кучи Java на две части: новое поколение и старое поколение, и принять разные стратегии сборки мусора для объектов с разным жизненным циклом и разным размером.

1.2.1 Молодое поколение

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

**Новое поколение разделено на три области:** область Эдема, две области выживших (S0, S1, также известные как From Survivor, To Survivor), большинство объектов генерируется в области Eden.

При заполнении области Эдема уцелевшие объекты будут скопированы в (одну из) двух областей Выживших; при заполнении области Выживших будут скопированы уцелевшие объекты в этой области, не соответствующие условиям повышения до старости. в другую область A Survivor. Каждый раз, когда объект подвергается репликации, его возраст увеличивается на 1, а после достижения порога возраста продвижения он переводится в старость.

1.2.2. Старое поколение

Объекты, пережившие N сборок мусора в молодом поколении, будут помещены в старое поколение, а выживаемость объектов в этой области высока. Сбор мусора в пожилом возрасте обычно использует алгоритм «отметить и отсортировать».

1.3 Классификация событий GC

По различным областям сбора и переработки мусора сбор мусора в основном делится на:

  • Young GC
  • Old GC
  • Full GC
  • Mixed GC

1.3.1. Young GC

Событие сборки мусора памяти молодого поколения называется Young GC (также известное как Minor GC).Молодой GC всегда запускается, когда JVM не может выделить новые объекты в пространстве памяти молодого поколения. Например, когда область Эдема заполнена, чем выше частота выделения новых объектов, тем выше частота Молодого GC.

Молодой GC будет каждый раз вызывать Stop-The-World, приостанавливая все потоки приложения, а время паузы почти ничтожно по сравнению с паузой, вызванной старым GC.

1.3.2. Old GC/Full GC/Mixed GC

Old GC: Только события GC, которые очищают пространство старого поколения, только параллельный сбор CMS - это режим.

Full GC: события GC для очистки всей кучи, включая новое поколение, старое поколение, метапространство и т. д.

Mixed GC: Очистить GC всего молодого поколения и части старого поколения, такой режим есть только у G1.

1.4 Анализ журнала GC

Журнал сборщика мусора — очень важный инструмент. Он точно фиксирует время выполнения и результаты выполнения каждого сборщика мусора. Анализируя журнал сборщика мусора, вы можете настроить параметры кучи и параметры сборщика мусора или улучшить режим выделения объектов в приложении.

Включенные параметры запуска JVM следующие:

-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps  -XX:+PrintGCTimeStamps

Общие журналы Young GC и Full GC имеют следующие значения:

  • Young GC

  • Full GC

Бесплатные инструменты анализа графика журнала GC рекомендуют следующие 2:

  • GCViewer: Загрузите пакет jar и запустите его напрямую.
  • gceasy: веб-инструмент, загрузка журналов GC для онлайн-использования.

1.5 Стратегия распределения памяти

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

1.5.1 Сначала объекты размещаются в области Эдема

В большинстве случаев объекты размещаются в области Эдема первого поколения. Когда в области Eden недостаточно места для выделения, виртуальная машина инициирует Young GC.

1.5.2 Крупные объекты входят в старость напрямую

JVM предоставляет пороговый параметр размера объекта (-XX:PretenureSizeThreshold, значение по умолчанию равно 0, что означает, что независимо от того, насколько он велик, память сначала выделяется в Eden).

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

1.5.3 Долгоживущие объекты вступают в старость

Каждый раз, когда объект подвергается сборке мусора и не собирается, его возраст увеличивается на 1. Объекты, размер которых превышает параметр порога возраста (-XX:MaxTenuringThreshold, по умолчанию 15), будут переведены в устаревший возраст.

1.5.4. Гарантия распределения места

Перед выполнением Young GC JVM должна оценить, может ли старое поколение разместить уцелевшие объекты, перемещенные из молодого поколения в старое поколение после Young GC, чтобы определить, необходимо ли заранее запускать GC для восстановления. пространство старого поколения, которое рассчитывается на основе гарантийного полиса выделения пространства.

Если Young GC проходит успешно (объекты, продвинутые после Young GC, могут быть помещены в старую), это означает, что гарантия выполнена успешно, и нет необходимости выполнять Full GC для повышения производительности.

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

1.5.5 Динамическое определение возраста

Возраст объекта молодого поколения может не достигать порогового значения (заданного параметром MaxTenuringThreshold), прежде чем он будет переведен в старое поколение.

Если после Young GC сумма размеров всех объектов одного возраста в выживших объектах молодого поколения будет больше половины любого пространства Survivor (пространство S0+S1), то область S0 или S1 вскоре не сможет вместить сохранившиеся объекты нового поколения.

Объекты с возрастом больше или равным этому возрасту могут перейти в старость напрямую, не дожидаясь возраста, требуемого в MaxTenuringThreshold.

Кроме того, если площади S0 или S1 после Young GC недостаточно для размещения: уцелевшие объекты молодого поколения, не соответствующие условиям продвижения старого поколения, приведут к тому, что эти уцелевшие объекты попадут непосредственно в старое поколение, что необходимо по возможности избегал.

2. Принцип и настройка CMS

2.1 Терминология Объяснение

2.1.1 Алгоритм анализа достижимости

Используется для определения того, является ли объект живым, основная идея состоит в том, чтобы использовать серию объектов, называемых «GC Root», в качестве отправной точки (общие корни GC включают загрузчик системных классов, объекты в стеке, активные потоки и т. д.), основанные на в ссылках на объекты Отношения начинаются с корней GC и ведут поиск вниз, а пройденный путь называется цепочкой ссылок.Когда у объекта нет цепочки ссылок, связанной с корнем GC, это доказывает, что объект больше не жив.

2.1.2. Stop The World

Отношение ссылки на объект анализируется во время процесса GC. Чтобы обеспечить точность результатов анализа, необходимо приостановить все потоки выполнения Java, чтобы гарантировать, что отношение ссылки больше не изменяется динамически. Это событие паузы называется Stop The World. (СТВ).

2.1.3. Safepoint

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

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

2.2. Введение в алгоритм CMS

CMS (Concurrent Mark and Sweep concurrency-mark-sweep) — это алгоритм сборки мусора, основанный на параллелизме и использующий алгоритм mark-sweep, который выполняет сборку мусора только для старых.

Когда сборщик CMS работает, поток GC и пользовательский поток должны выполняться одновременно, насколько это возможно, чтобы сократить время STW.

Включите сборщик мусора CMS со следующими параметрами командной строки:

-XX:+UseConcMarkSweepGC

Стоит добавить, что описанный ниже сборщик мусора CMS относится к сборщику мусора старого поколения, тогда как полный сборщик мусора относится к событиям сборщика мусора всей кучи, включая новое поколение, старое поколение и метапространство.

2.3 Сборка мусора нового поколения

Сборщики мусора нового поколения, которые можно использовать с CMS, — это сборщик Serial и сборщик ParNew.

Эти два сборщика используют алгоритм копирования метки и запускают событие STW, чтобы остановить все потоки приложения. Разница в том, что Serial является однопоточным, а ParNew — многопоточным.

2.4. Вывоз мусора для пожилых людей

Целью CMS GC является получение минимального времени паузы и минимизация времени STW, его можно разделить на 7 этапов:

2.4.1 Начальная отметка

Цель начальной фазы маркировки — пометить все уцелевшие объекты в старом поколении, включая прямые ссылки на корень GC и объекты, на которые ссылаются уцелевшие объекты в молодом поколении, инициировав первое событие STW.

Этот процесс поддерживает многопоточность (один поток до JDK7, параллельный после JDK8, что можно настроить параметром CMSPallelInitialMarkEnabled).

2.4.2. Параллельная отметка

На этапе параллельной маркировки поток GC и поток приложения выполняются одновременно, обходят уцелевшие объекты, первоначально отмеченные на этапе 1, а затем продолжают рекурсивно помечать объекты, достижимые этими объектами.

2.4.3 Параллельная предварительная очистка

На параллельной фазе предварительной очистки поток GC и поток приложения также выполняются одновременно.Поскольку этап 2 выполняется одновременно с потоком приложения, некоторые отношения ссылок могут измениться.

Посредством маркировки карт пространство старости заранее логически разделено на равные по размеру области (карты).

Если эталонное отношение изменится, JVM пометит измененную область как «грязную карту», ​​а затем на этом этапе эти грязные области будут найдены, эталонное отношение будет обновлено, а пометка «грязная область» будет очищена.

2.4.4. Параллельная прерываемая предварительная очистка

Параллельная отменяемая фаза предварительной очистки также не останавливает поток приложения. На этом этапе делается попытка выполнить как можно больше работы перед фазой Final Remark STW, чтобы сократить время паузы приложения.

На этом этапе обработка цикла: помечать достижимые объекты в старом поколении, сканировать и обрабатывать объекты в области Dirty Card, а условия завершения цикла таковы:

  • количество достигнутых циклов
  • Достигнуто пороговое значение времени выполнения цикла
  • Использование памяти нового поколения достигает порога

2.4.5 Заключительное замечание

Это вторая (и последняя) фаза STW в событии GC, и цель состоит в том, чтобы завершить маркировку всех живых объектов в старом поколении.На этой фазе выполняются:

  • Обход объектов нового поколения и повторная маркировка
  • Замечание по GC Roots
  • Пройдитесь по старым грязным картам и перемаркируйте их.

2.4.6 Параллельная проверка

Параллельная фаза очистки выполняется одновременно с приложением без паузы STW, а объекты мусора очищаются в соответствии с результатом маркировки.

2.4.7. Параллельный сброс

Фаза параллельного сброса выполняется одновременно с приложением, сбрасывает внутренние данные, связанные с алгоритмом CMS, и готовится к следующему циклу GC.

2.5 Часто задаваемые вопросы о CMS

2.5.1 Финальная фаза маркировки слишком длинная.

Около 80% времени паузы GC CMS находится в фазе финальной маркировки (Final Remark).Если время паузы в этой фазе слишком велико, распространенной причиной является недопустимая ссылка нового поколения на старое поколение. цикл не завершается в течение порогового времени выполнения, и уже слишком поздно запускать Young GC для очистки этих недопустимых ссылок.

Добавив параметр: -XX:+CMSScavengeBeforeRemark.

Запустите Young GC перед выполнением последней операции, тем самым уменьшив недопустимую ссылку молодого поколения на старое поколение и уменьшив паузу на заключительном этапе маркировки.

Но если Young GC был запущен на предыдущем этапе (одновременная отменяемая предварительная очистка), Young GC также запускается повторно.

2.5.2. Сбой параллельного режима и сбой продвижения

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

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

Сбой параллельного режима и сбой продвижения приведут к длительной паузе. Распространенные решения:

  • Уменьшите порог срабатывания CMS GC

    То есть значение параметра -XX:CMSInitiatingOccupancyFraction, пусть CMS GC выполнится как можно быстрее, чтобы убедиться, что места достаточно

  • Увеличьте количество потоков CMS, то есть параметр -XX:ConcGCThreads

  • Увеличить пространство старости

  • Пусть объект максимально перерабатывается в новом поколении, чтобы не попасть в старое поколение

2.5.3 Проблемы с фрагментацией памяти

Обычно процесс GC в CMS основан на алгоритме маркировки-очистки без действия уплотнения, что приводит к все большей и большей фрагментации памяти, требующей уплотнения.

Следующие распространенные сценарии вызывают сжатие фрагментации памяти:

  • Новое поколение Young GC имеет сбой гарантии продвижения нового поколения (продвижение не удалось)
  • Программа активно выполняет System.gc()

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

Значение по умолчанию — 0, что означает, что сжатие будет запускаться каждый раз, когда он входит в полный сборщик мусора.Алгоритм с действием сжатия — это упомянутый выше однопоточный алгоритм Serial Old, а время паузы (STW) очень велико, поэтому необходимо максимально сократить время сжатия.

3. Принцип G1 и настройка

3.1 Введение в G1

G1 (Garbage-First) — серверно-ориентированный сборщик мусора, который поддерживает сборку мусора пространств нового и старого поколения, в основном для машин, оснащенных многоядерными процессорами и памятью большого объема.

Основной целью разработки G1 является достижение предсказуемого и настраиваемого времени пребывания STW.

3.2 Разделение пространства кучи G1

3.2.1. Region

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

Логически, все объединенные области Эдема и области Выживших представляют собой новое поколение, а все старые области объединены в старое поколение, а соответствующие области памяти нового поколения и старого поколения автоматически контролируются G1 и постоянно меняются.

3.2.2 Гигантские объекты

Когда размер объекта превышает половину Региона, он считается Огромным Объектом и напрямую относится к Огромным Регионам старого поколения.

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

Значение G1, разделяющего память кучи на регионы, заключается в следующем:

  • Каждый GC не должен иметь дело со всем пространством кучи, а каждый раз обрабатывается только часть Region для реализации GC памяти большой емкости.
  • Путем расчета значения утилизации для каждого региона, включая время, необходимое для переработки, и доступное для повторного использования пространство, максимально возможное количество объектов мусора перерабатывается за ограниченное время, а время паузы, вызванное сборкой мусора, контролируется в пределах ожидаемого диапазона времени конфигурации. Происхождение названия G1: Garbage-First.

3.3 Рабочий режим G1

Для нового поколения и старого поколения G1 предоставляет 2 режима GC, Young GC и Mixed GC, два из которых вызовут Stop The World.

3.3.1. Young GC

Когда пространства молодого поколения недостаточно, G1 запускает Young GC, чтобы вернуть пространство молодого поколения.

Молодой GC в основном выполняет GC на области Эдема.Он срабатывает, когда пространство Эдема исчерпывается.Основываясь на идее алгоритма повторного использования и репликации поколений, каждый Молодой GC будет выбирать все регионы нового поколения.

В то же время подсчитывается пространство области Эдема и области Выживших, необходимое для следующего Молодого GC, а количество Регионов, занятых новым поколением, динамически корректируется для контроля накладных расходов Молодого GC.

3.3.2. Mixed GC

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

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

3.4. Глобальный маркер параллелизма

Глобальная одновременная оценка в основном предназначена для выявления регионов с более высоким доходом восстановления для расчета смешанного GC, который разделен на 5 этапов:

3.4.1 Начальная отметка

Приостановите все потоки приложения (STW) и одновременно отметьте объекты (собственные объекты стека, глобальные объекты, объекты JNI), которые напрямую доступны из корня GC.

Когда условие триггера достигнуто, G1 не сразу инициирует параллельный цикл маркировки, а ожидает следующей коллекции нового поколения и использует период времени STW, собранный новым поколением, для завершения начальной маркировки.Этот метод называется Piggybacking.

3.4.2 Сканирование корневого региона

После того, как начальная пауза пометки заканчивается, новое поколение собирает и завершает работу по копированию объектов в Survivor, и поток приложения становится активным.

В это время, чтобы обеспечить корректность алгоритма маркировки, всем объектам, вновь скопированным в раздел Survivor, необходимо выяснить, какие объекты имеют ссылки на объекты в старости, и пометить эти объекты как корни.

Этот процесс называется сканированием корневого региона, а отсканированный раздел Suvivor также называется корневым регионом.

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

3.4.3. Параллельная Маркировка

Поток маркировки выполняется параллельно с потоком приложения, чтобы пометить оставшуюся информацию об объекте Region в каждой куче.Этот шаг может быть прерван новым GC Young.

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

3.4.4 Замечание

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

3.4.5. Очистка

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

  • Упорядочить и обновить соответствующий набор RSet (запомнить набор, структуру HashMap каждого региона, записать, какие объекты старости указывают на этот регион, ключ — это ссылка на объект, указывающий на этот регион, значение — это конкретная область карты, указывающая на этот регион, Регион можно определить с помощью информации о выживании объекта RSet, избегайте полного сканирования кучи)
  • Восстановить регионы, не содержащие живых объектов
  • Статистически рассчитать коллекцию устаревших разделов с высокой отдачей при восстановлении (на основе свободного места и целей паузы).

3.5 Примечания по настройке G1

3.5.1 Полная задача GC

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

Общие причины следующие:

  • Программа активно выполняет System.gc()
  • Пространство старого поколения заполнено во время глобальной параллельной маркировки (сбой параллельного режима)
  • Пространство старого поколения заполнено во время Mixed GC (продвижение не удалось)
  • Пространство выжившего и старость не имеют достаточно места для выживших объектов во время Young GC

Как и в случае с CMS, распространенными решениями являются:

  • Увеличение параметра -XX:ConcGCThreads=n увеличивает количество параллельных потоков маркировки или параллельных потоков во время STW: -XX:ParallelGCThreads=n.
  • Уменьшите -XX:InitiatingHeapOccupancyPercent, чтобы начать период маркировки раньше.
  • Увеличьте зарезервированную память -XX:G1ReservePercent=n, значение по умолчанию равно 10, что означает, что 10% памяти кучи используется в качестве зарезервированной памяти. использовать зарезервированную память.

3.5.2. Распределение огромных объектов

Каждая область в области гигантских объектов содержит гигантский объект, а оставшееся пространство больше не используется, что приводит к фрагментации пространства.Когда G1 не имеет подходящего места для размещения гигантских объектов, G1 запускает серийный полный сборщик мусора, чтобы освободить пространство.

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

3.5.3 Не задавать размер области Юнга

Причина в том, что для максимального соблюдения целевого времени паузы логическая область Юнга будет динамически корректироваться. Если установлен размер, он будет переопределен, и управление временем паузы будет отключено.

3.5.4 Настройки среднего времени отклика

Используйте среднее время отклика приложения в качестве эталона для установки MaxGCPauseMillis, JVM попытается выполнить это условие, это может быть 90% запросов или больше времени отклика в пределах этого, но это не означает, что все запросы могут быть удовлетворены , среднее Слишком маленькое время отклика приведет к частому сбору мусора.

4. Методы и идеи тюнинга

Как проанализировать состояние работы JVM GC в системе и правильно его оптимизировать?

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

4.1. Анализ работоспособности системы

Для анализа работоспособности системы:

  • Количество запросов в секунду, сколько объектов создается за запрос и сколько памяти занято.
  • Частота срабатывания молодого GC, скорость, с которой объекты достигают старости.
  • Память, занимаемая старым поколением, частота срабатывания Full GC, причины срабатывания Full GC и причины длительного срабатывания Full GC.

Общие инструменты следующие:

4.1.1. jstat

jstat — это инструмент командной строки, поставляемый с JVM, который можно использовать для подсчета скорости выделения памяти, времени GC и времени GC. Общий формат команды следующий:

jstat -gc <pid> <统计间隔时间>  <统计次数>

Значение выходного возвращаемого значения следующее:

Например: jstat -gc 32683 1000 10 для подсчета процессов с pid=32683, 1 раз в секунду, 10 раз.

4.1.2. jmap

jmap также является инструментом командной строки, поставляемым с JVM, который можно использовать для понимания распределения объектов во время работы системы. Общий формат команды следующий:

// 命令行输出类名、类数量数量，类占用内存大小，
// 按照类占用内存大小降序排列
jmap -histo <pid>

// 生成堆内存转储快照，在当前目录下导出dump.hrpof的二进制文件，
// 可以用eclipse的MAT图形化工具分析
jmap -dump:live,format=b,file=dump.hprof <pid>

4.1.3. jinfo

Расширенные параметры для просмотра запущенных приложений Java, включая свойства системы Java и параметры командной строки JVM. Формат команды следующий:

jinfo <pid>

4.1.4 Другие инструменты GC

  • Мониторинг охранной сигнализации: Zabbix, Prometheus, Open-Falcon
  • инструмент автоматического мониторинга памяти jdk в реальном времени: VisualVM
  • Мониторинг памяти вне кучи: Java VisualVM устанавливает плагин Buffer Pools, инструмент Google perf, инструмент Java NMT (Native Memory Tracking)
  • Анализ журнала сборщика мусора: GCViewer, gceasy
  • Проверка и оптимизация параметров ГХ:xxfox.perfma.com/

4.2 Случай оптимизации сборщика мусора

4.2.1. Частый полный сбор мусора в системе платформы анализа данных

Платформа в основном проводит регулярный анализ и статистику поведения пользователя в приложении, а также поддерживает экспорт отчетов с использованием алгоритма CMS GC.

За время использования аналитик данных обнаружил, что системная страница часто зависала при открытии.С помощью команды jstat было установлено, что около 10% выживших объектов уходили в старость после каждого Young GC.

Получается, что из-за того, что места в области Survivor слишком мало, уцелевшие объекты нельзя размещать в области Survivor после каждого GC Young, и они входят в старость заранее.

Увеличивая область Survivor, область Survivor может вместить выжившие объекты после Young GC.Объекты в области Survivor проходят через несколько Young GC и достигают возрастного порога, прежде чем войти в старость.

После корректировки уцелевшие объекты, входящие в старое поколение, после каждого Young GC стабильно работают всего несколько сотен Кб, а частота Full GC сильно снижается.

4.2.2 Шлюз межсетевого взаимодействия OOM

Шлюз в основном потребляет данные Kafka, выполняет обработку и расчет данных, а затем перенаправляет их в другую очередь Kafka.OOM возникает, когда система работает в течение нескольких часов, а OOM возникает через несколько часов после перезапуска системы.

Память кучи выгружается через jmap, а причина выясняется после анализа eclipse MAT tool: В коде асинхронно в логе печатаются топик-данные определенного бизнеса Kafka.Объем бизнес-данных большой, и в памяти накапливается большое количество объектов, ожидающих печати, что приводит к OOM.

4.2.3 Система аутентификации часто выполняет полную сборку мусора в течение длительного времени

Система предоставляет различные услуги аутентификации учетной записи для внешнего мира.При ее использовании обнаруживается, что система часто недоступна.Благодаря мониторингу платформы мониторинга Zabbix обнаружено, что в системе часто происходит полный GC в течение длительного времени, и память кучи старого поколения обычно не заполняется при ее срабатывании System.gc() вызывается в бизнес-коде.

резюме

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

Из-за нехватки места мы не будем вводить использование общих параметров GC.Вы можете клонировать с GitHub:

https://github.com/caison/caison-blog-demo

Ссылаться на

  • Производительность Java: полное руководство Скотта Оукса
  • «Понимание виртуальной машины Java: расширенные функции и лучшие практики JVM (второе издание», Чжихуа Чжоу)
  • Настройка производительности Java в действии
  • Getting Started with the G1 Garbage Collector
  • Справочное руководство по ГХ — версия для Java
  • Спросите принцип алгоритма G1 - ответ RednaxelaFX
  • Некоторые ключевые технологии Java Hotspot G1 GC - Техническая команда Meituan

Перепечатано: Чен Цайхуа (caison), инженер по разработке основных технологий Akulaku, любит изучать распределенные системы, онлайн-устранение неполадок и проектирование архитектуры.

О публичном номере

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

Категории