предисловие
Эта статья, организованная сегодня, составлена из ежедневных заметок, записанных ранее.
Когда я впервые столкнулся с JVM, я придерживался «избегающего» отношения к журналам GC.Когда программы, развернутые в сети, не достигали ожидаемой операционной эффективности или ожидаемых целей, проблема часто указывалась на память.
Не хватает памяти?
Почему так много журналов GC? Сколько гигабайт занимает диск?
Я не хочу видеть, сколько печатаю, да еще насильно блокирую журнал программы.
Я тоже делал это, и программы, которые я написал, также вызывали переполнение памяти и даже простои хост-машины.
Да, сборка мусора в java действительно спасает нас от многих вещей, мы не такие, как программисты на C/C++,
Необходимо рассмотреть выделение памяти (malloc) и (свободное) освобождение памяти, но я считаю, что каждый партнер по разработке Java
Будут проблемы с GC, будь то оптимизация производительности программы или анализ сбоев.
Мы должны снова и снова набираться опыта и уроков на ошибках, вместо того, чтобы убегать или решать проблемы поспешно. Одна и та же точка знаний, пересмотренная дважды, даст эффект 1 + 1 > 2.
Итак, в этой статье поговорим о знакомом логе JVM GC.
что такое журнал GC
Прежде всего, поговорим о понятии GC, GC — это аббревиатура от Garbage Collection.
Что такое мусор?
Объект, на который нет ссылок, рассматривается JVM как мусор.
Конечно, соответствующими алгоритмами оценки являются: алгоритм подсчета ссылок и алгоритм анализа достижимости. Соответствующие алгоритмы переработки: удаление меток, репликация, сортировка меток и алгоритмы сбора поколений.
Что такое журнал GC?
Журнал GC представляет собой описательный текстовый журнал, созданный виртуальной машиной Java. Так же, как нам нужно выводить журналы журналов при разработке java-программ. Виртуальная машина JAVA использует журнал GC для описания ситуации сборки мусора.
Малый GC и основной GC
Второстепенный GC, представляющий GC нового поколения, относится к действию сборки мусора, которое происходит в новом поколении.Все второстепенные GC вызывают остановку мира, чтобы остановить потоки приложения, но этот процесс очень короткий.
Большой ГК: Старческий ГК относится к ГК, возникающему в пожилом возрасте, также известному как Полный ГК.
Для чего используются журналы GC
Через журнал GC мы можем интуитивно увидеть основной рабочий процесс очистки памяти.
Узнайте о некоторых режимах сборки мусора, когда перерабатывать в Young (молодое поколение) и когда в Old (старое поколение), и покажите, сколько ресурсов используется сборкой мусора.
Хотя сейчас существует множество инструментов визуального мониторинга для Java-программ [Introduction? ], но журнал GC — это одна из наиболее интуитивно понятных сведений для разработчиков, позволяющая быстро обнаруживать потенциальные сбои памяти и узкие места в производительности.
Какую информацию мы можем получить из журналов GC
Сбой выделения GC для ES
Журнал при столкновении с онлайн-проблемами GC также является ценным материалом для анализа.Изображение GC Allocation Failure здесь цитируется из журнала GC узла ES друга группы.
GC Allocation Failure — это разновидность журнала GC, с которым мы часто сталкиваемся.
Ошибка выделения означает, что больше нет места для выделения объектов в области Eden JVM, которая является обычным журналом второстепенного GC.
Тогда не будем просто говорить об этом, давайте посмотрим, как выглядит содержимое журнала GC Allocation Failure.
Чувствуете себя грязно? 【Отрежь себе голову и говори】
Не беда, давайте анализировать и анализировать по очереди.
Делим по времени, мы знаем, что на скриншоте две строки логов, давайте сначала посмотрим на лог один:
2020-03-17T19:03:19.701+0800: 6664.686:
Total time for which application threads were stopped: 0.0313360 seconds
, Stopping threads took: 0.0000925 seconds
Излишне говорить, что первое, что бросается в глаза, это лог времени с часовым поясом.
Во-вторых, общее время, в течение которого потоки приложения были остановлены. Указывает, что все потоки приложения были приостановлены на 0,0313360 секунд.
Потребовалось 0,0000925 секунд, чтобы дождаться, пока все потоки приложения достигнут [безопасной точки].
Время паузы фактически тратится на GC. Этому соответствует real=0,03 секунды в последующей второй строке.
Только что упомянул о безопасности, просто упомянем, что мы знаем, что потоки в Java имеют несколько разных состояний. Также знайте, какие проблемы могут возникнуть, если поток «прерван». Таким образом, для дизайнера необходимо позволить потоку «дойти» до безопасной точки, а затем остановиться. В безопасной точке состояние потока является детерминированным, поэтому JVM может безопасно выполнять некоторые операции, например сборку мусора.
К безопасным точкам относятся:
Если есть потоки, которые не вошли в безопасную точку, время паузы JVM во время GC будет увеличено.
Давайте посмотрим на журнал два:
1） 2020-03-17T19:03:20.118+0800: 6665.102:
2）[GC (Allocation Failure) 2020-03-17T19:03:20.118+0800: 6665.102:
3）[ParNew Desired survivor size 8716288 bytes, new threshold 6 (max 6)
4）- age 1: 6826872 bytes, 6826872 total
5）- age 2: 1060216 bytes, 7887088 total
6）: 149828K->8895K(153344K), 0.0361997 secs]
7）6272826K->6139400K(8371584K),0.0363166 secs]
8） [Times: user=0.07 sys=0.00, real=0.03 secs]
Первая строка — время вывода журнала.
Вторая строка указывает, что было выполнено восстановление GC.Обратите внимание, что, поскольку здесь нет ключевого слова Full, это указывает на то, что это второстепенный GC, и указывает время GC. Ошибка распределения указывает на то, что причиной GC является нехватка места для хранения данных в молодом поколении.
В третьей строке ParNew также указывает, что этот GC происходит в молодом поколении, и используется сборщик мусора ParNew. Сборщик использует алгоритм репликации для высвобождения памяти, во время которого другие рабочие потоки будут остановлены, то есть Stop The World.
Третья, четвертая и пятая строки представляют возрастное распределение объектов в области выживания, напечатанное после каждого GC молодого поколения. порог указывает, что установленный возрастной порог для продвижения старого поколения равен 6.
Шестая строка представляет собой использованную мощность молодого поколения до GC и используемую мощность этой области после GC, а в скобках указана общая мощность этой области. Наконец, время GC области памяти в секундах.
Седьмая строка представляет размер кучи до сборки мусора, размер кучи после сборки мусора и общий размер области кучи.
Видно, что после GC доля переработанных объектов очень мала.
Восьмая строка показывает три затраты времени, а именно затраты времени в пользовательском режиме, затраты времени в режиме ядра и общие затраты времени.
Из приведенной выше информации мы можем сделать следующие выводы:
Это молодое поколение GC сокращается: 149828 - 8895 = 140933К.
Общая площадь памяти кучи уменьшена: 6272826 - 6139400 = 133426К.
Затем вычтите результаты после двух знаков равенства: 140933 - 133426 = 7507К
Это показывает, что на этот раз из молодого поколения в старое было перенесено в общей сложности 7507 КБ (7,3 М) памяти.Видно, что число невелико, что указывает на то, что все они являются объектами с коротким жизненным циклом, но таких объектов много.
Что нам нужно, так это максимально избежать возникновения Full GC, и позволить объектам как можно больше перерабатываться в молодом поколении, поэтому здесь мы можем немного увеличить размер молодого поколения, чтобы 7.3M данных сохраняется и в молодом поколении.
Старый GC от ES
Лог GC молодого поколения представлен выше, давайте поговорим о логе GC старого поколения, который фактически совпадает с методом анализа молодого поколения.
Или сначала перечислите журналы:
[gc][238384] overhead, spent [2.2s] collecting in the last [2.3s]
[2020-03-18T01:01:29,020][INFO ][o.e.m.j.JvmGcMonitorService]
[eS] [gc][old][238385][160772] duration [5s],
collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb],
all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}
Давайте просто объясним. Первая строка указывает, что это 238384-й сборщик мусора, который потратил 2,2 с на сборку мусора за последние 2,3 с.
Я считаю, что после прочтения ГК молодого поколения понять смысл второй строки несложно.
[gc][Это старый GC][Это 228385-я проверка GC][160772-й GC, который произошел с момента запуска JVM] продолжительность [Общее время проверки сборщика мусора на этот раз составляет 5 секунд, что может быть суммой нескольких раз],
collections [Всего 1 GC с момента последней проверки]/[5,1 секунды с момента последней проверки],
total [Общее время, затраченное на GC, проверенное на этот раз, составляет 5 секунд]/[Общее время, затраченное на GC с момента запуска JVM до настоящего времени, составляет 4,4 дня],
memory [Пространство памяти кучи до GC]->[Объем памяти кучи после GC]/[Общее пространство памяти кучи],
all_pools (детали генерационной части)
{[молодая область][Память до сборки мусора]->[Память после сборки мусора]/[Общий объем памяти молодой области] }
{[область выжившего][Память до GC]->[Память после GC]/[Общий объем памяти в области Survivor]}{[старая область][Память до GC]->[Память после GC]/[Общий объем память в старой области ] }
Конфигурация ES GC
-XX:+PrintGCDetails означает распечатать подробный журнал GC
-XX:+PrintGCDateStamps указывает, что необходимо отобразить дату и время печати GC.
-XX:+PrintGCApplicationStoppedTime Распечатать время, когда программа была приостановлена во время сборки мусора
Прокат журнала, вывод в указанный файл журнала и т. д.
Значок журнала GC
Если предыдущее введение не слишком понятно, вот два изображения журнала GC, которые можно использовать в качестве инструмента, когда вам нужно будет читать журнал GC в будущем.
Молодое поколение:
Старость:
Резюме (мое мнение)
Сборщик мусора имеет много знаний.Эта статья может быть только верхушкой айсберга.Начиная с анализа журнала сборщика мусора, читатели могут понять, что означает изменение каждого числа в журнале сборщика мусора. Более того, я ранее представил некоторые онлайн-идеи устранения неполадок OOM и использования инструментов анализа производительности MAT в реальных кейсах.В то же время, я надеюсь, вы проанализируете больше реальных кейсов и сделаете хороший запас знаний, то есть GC онлайн , Некоторые проблемы также можно решить, настроив оптимальную конфигурацию JVM, повысив эффективность работы онлайн-программ и постаравшись избежать некоторых сбоев в производительности. Наконец, сделайте вывод о содержании
- В этой статье описаны причины организации этой заметки
- Знакомит с основными понятиями журналов сборщика мусора.
- Основные понятия малого GC и большого GC
- Объясняет роль журнала GC
- Лог-интерпретация ошибки выделения ES GC
- Лог-интерпретация старого GC от ES.
- Схема JAVA GC
Рекомендуется присоединиться к группе решения сложных проблем Java, а также рекомендуется прочитать
[Реальный бой] Обмен данными об улучшении скорости записи в elasticsearch
Эффективный импорт миллионов данных Mysql в Redis
Визуальный интерфейс генерирует параметры JVM онлайн