резюме
Анализ производительности Java — это искусство и наука. Наука относится к анализу производительности, обычно включающему большое количество чисел, измерений и анализа; искусство относится к использованию знаний, опыта и интуиции. Инструменты или средства анализа производительности разные, но и процесс анализа производительности совсем другой. В этой статье представлены некоторые известные и применимые советы по анализу производительности Java, которые помогут пользователям лучше понять и использовать их.
Совет 1. Анализ стека потоков
Анализ стека потоков — это моментальный анализ запущенных потоков Java. Это упрощенный метод анализа. Пользователи могут сначала попробовать его, если не знают, какие проблемы с производительностью существуют в приложении. Хотя единого стандарта для определения того, является ли поток Java ненормальным, не существует, пользователи могут делать количественные оценки с помощью некоторых индикаторов. Следующие четыре индикатора обнаружения являются общими:
1) Проверка взаимоблокировки потокаПроверка взаимоблокировки потока — очень ценный индикатор обнаружения. Если поток заблокирован, как правило, это приводит к пустой трате системных ресурсов или снижению возможностей обслуживания. После обнаружения его необходимо вовремя устранить. При обнаружении взаимоблокировки потока будет отображаться взаимосвязь взаимоблокировки потока и соответствующая информация о стеке.Благодаря анализу может быть обнаружен код, вызывающий взаимоблокировку. Модель взаимоблокировки, показанная на рис. 1, показывает сложный сценарий взаимоблокировки с 4 потоками.
2) Проверить статистику тредаСтатистика состояния — это статистика и сводка запущенных потоков в соответствии с их рабочим статусом. Когда пользователи не до конца осознают свои собственные бизнес-требования, они обычно настраивают очень достаточный диапазон количества доступных потоков, что приведет к снижению производительности или истощению системных ресурсов из-за слишком большого количества потоков. Как показано на рис. 2, можно обнаружить, что более 90 % потоков находятся в заблокированном и ожидающем состоянии, поэтому правильная оптимизация количества потоков может уменьшить накладные расходы, вызванные планированием потоков и ненужной тратой ресурсов.
Как показано на рисунке 3, количество потоков в рабочей фазе превысило 90% Дальнейший анализ может привести к проблеме утечки потока. В то же время запущенных потоков слишком много, и накладные расходы на переключение потоков тоже очень велики.
3) Проверка использования ЦП потокомИспользование ЦП каждым потоком Java подсчитывается и сортируется, а стек потоков с чрезвычайно высокой загрузкой ЦП анализируется для быстрого обнаружения горячих точек программы. Как показано на рис. 4, загрузка ЦП первого потока задачи достигла 100 %, и разработчик может определить, следует ли оптимизировать код в соответствии с бизнес-логикой.
4) Проверка количества потоков GCКоличество потоков GC часто является показателем, который пользователи легко упускают из виду. При настройке количества параллельных потоков GC пользователи, как правило, игнорируют системные ресурсы или произвольно развертывают приложения на физических машинах с большим количеством ядер ЦП. Как показано на рис. 5, мы обнаружили, что в 4-ядерном 8-гигабайтном контейнере количество параллельных потоков сбора G1 равно 9 (как правило, количество параллельных потоков GC составляет 1/4 от количества потоков задач GC), то есть, когда происходит GC. Когда есть 9 параллельных потоков GC, ресурсы ЦП будут напрямую исчерпаны за короткое время, и система и бизнес будут заблокированы. Поэтому при использовании сборщиков GC (таких как CMS, G1) установите или обратите внимание на максимально возможное количество потоков GC.
Совет 2. Анализ журнала сборщика мусора
Анализ журнала — это анализ данных, собранных и записанных Java-программой GC, и сбор этой части данных требует включения определенных параметров. Поэтому обязательно добавьте параметры журнала перед запуском программы Java (например, JDK8: -Xloggc:logs/gc-%t.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps; JDK11: -Xlog:gc*:logs/ gc-%t.log:время,время безотказной работы). Результаты анализа журнала сборщика мусора описывают состояние освобождения памяти программами Java за определенный период времени. Анализируя эту информацию о состоянии, пользователи могут легко получить параметры сборщика мусора и даже данные индикатора оптимизации кода Java. Расширены следующие три индикатора анализа:
1) Производительность ГХПропускная способность описывает долю времени, которое может быть использовано для бизнес-обработки в течение периода времени работы JVM, то есть время, не занятое GC. Чем больше значение, тем меньше времени занимает пользовательская сборка мусора и тем выше производительность JVM. Значение, указанное внутри JVM, не может быть ниже 90%, иначе потеря производительности, вызванная самой JVM, серьезно повлияет на эффективность бизнеса. На Рисунке 6 показаны результаты анализа лога JDK8 CMS, проработавшей около 3 ч. Результаты анализа показывают, что его пропускная способность превышает 99,2%, а потери производительности, вызванные JVM (GC), относительно невелики.
2) Статистика времени паузыВремя паузы GC относится к времени, когда бизнес-поток должен быть остановлен во время процесса GC, и это время должно находиться в разумных пределах. Если большая часть времени пауз превышает ожидания (диапазон, приемлемый для пользователей), необходимо настроить параметры GC и размер кучи и даже задать количество параллельных потоков GC. Как показано на рисунке 7, более 95% времени паузы GC находится в пределах 40 мс, а время паузы более 100 мс может быть основным фактором, вызывающим сбой времени запроса на обслуживание. Чтобы устранить проблему колебаний времени паузы, вы можете выбрать G1 GC или ZGC или настроить количество параллельных потоков или параметры GC.
3) График рассеяния стадии GCТочечная диаграмма отражает распределение объема памяти, освобождаемой каждой операцией сборки мусора. Как показано на рисунке 8, размер памяти, освобождаемой каждым сборщиком мусора, в основном одинаков, что указывает на то, что процесс освобождения памяти относительно стабилен. Однако, если имеется относительно большое колебание или имеется много полных GC, может оказаться, что места в куче в области нового поколения недостаточно, что приводит к большому количеству продвижения; если количество релизов на GC относительно невелико, это может быть новое поколение, вызванное адаптивным алгоритмом G1 GC.Пространство поколений мало и т. д. Поскольку данные, отображаемые на точечной диаграмме, ограничены, обычно необходимо комбинировать другие индикаторы и параметры JVM пользователя для совместного анализа.
Совет 3: Анатомия инцидента JFR
JFR — это аббревиатура от Java Flight Record, которая представляет собой основанную на событиях среду мониторинга и записи JDK, встроенную в JVM. В сообществе JFR был выпущен на OpenJDK11 с приоритетом, а затем перенесен на более высокую версию 260 OpenJDK8 и следовал унифицированному интерфейсу использования и рабочей команде jcmd. В то же время, поскольку запись JFR, как правило, мало влияет на приложение (влияние на производительность открытия по умолчанию находится в пределах 1%), она подходит для долгосрочного открытия, а JFR может собирать обширную информацию, такую как время выполнения, GC, стек потоков, куча, ввод-вывод и т. д., что очень удобно для пользователей, чтобы понять текущее состояние программ Java. JFR регистрирует более 100 видов событий.Если программа сложная, размер файла JFR, записанного менее чем за 10 минут, превысит 500 МБ, поэтому пользователи часто не обращают внимания на всю информацию при анализе. Ниже приведены некоторые общие показатели эффективности бизнеса, которыми можно поделиться:
1) Процесс использования ЦПИнтервал по умолчанию для выборки ЦП составляет 1 с, что в основном может своевременно отражать среднее использование ЦП текущим процессом. Определенное обнаружение и анализ могут быть выполнены, когда загрузка ЦП продолжает оставаться высокой или когда загрузка ЦП время от времени всплескивается, как показано на рисунке 9. Благодаря дальнейшему позиционированию всплеск ЦП здесь согласуется со временем запуска GC, и изначально подтверждается, что изменение ЦП, вызванное GC, соответствует.
2) Конфигурация GC и приостановка распространенияКонфигурация GC может помочь нам понять сборщик GC текущего процесса и его основные параметры конфигурации, потому что характеристики разных сборщиков будут разными, а также очень важно проанализировать такие параметры, как место в куче и управление триггером. Параметры управления могут помочь нам понять процесс сбора сборщика мусора, например сборщик G1, показанный на рис. ожидаемое значение. Дальнейший анализ параметров показал, что значение NewRatio было установлено равным 2 (если вы не знакомы с G1 GC, пользователи могут легко установить этот параметр), что приводит к частым запускам GC в области нового поколения, и смешанный GC не запускается из данные. Чтобы увеличить использование пространства кучи, вы можете удалить параметр NewRatio, увеличить максимальное соотношение области новой генерации (поскольку смешанный GC не срабатывает, что указывает на то, что количество продвижения при переработке кучи очень низкое), снизить порог рециркуляции для рециклируемых блоков и т.д. Использование всего стека. Благодаря оптимизации использование пространства кучи увеличено с первоначальных 4 ГБ до 7 ГБ, частота YGC увеличена с 20 секунд за раз до в среднем 40 секунд за раз, а время паузы GC существенно не изменилось.
3) Диаграмма пламени метода отбора пробПламенный график метода представляет собой статистику количества вызовов метода. Чем больше отношение, тем больше раз вызывается метод. Поскольку в процессе выборки имеется полная информация о стеке, она очень интуитивно понятна для пользователей, а помощь в оптимизации производительности значительно увеличивается. Как показано на рис. 11, отчетливо видно, что доля времени выполнения GroupHeap.match близка к 30%, что можно использовать в качестве точки оптимизации производительности.
4) производительность чтения и записи ввода-выводаПроверка производительности ввода-вывода — это в основном случай внезапных изменений производительности обработки программы, таких как падение или всплеск. Например, объем данных, считываемых из сокета, резко возрастает, что приводит к резкому увеличению нагрузки на ЦП, или из-за того, что необходимо записать больше данных, бизнес-поток блокируется, а вычислительная мощность снижается. Как показано на рис. 11, возможности ввода-вывода в течение периода мониторинга можно оценить по графику тенденции чтения/записи.
Совет 4: анализ содержимого кучи
Анализ содержания кучи - это общий метод анализа причина java кучи OOM (OutofmemoryError). OOM в основном включает в себя переполнение космоса кучи, переполнение мета пространства, переполнение пространства стека и переполнение прямой памяти и т. Д., Но не все ситуации переполнения могут быть получены посредством анализа содержания кучи. Для файлов сброса кучи, возможность переполнения памяти неясно, но она может быть оценена по некоторым количественным показателям или согласованным условиям, а затем окончательное подтверждение разработчиков или тестеров. Вот три ценные метрики для поделиться:
1) Проверка крупных объектовСтатистика распределения больших объектов может помочь нам понять долю потребления памяти этими объектами и разумность существующих больших объектов. Слишком много больших объектов, которые невозможно освободить, быстро исчерпают память и вызовут неработоспособность.По сравнению с полным анализом всех объектов проверка больших объектов является репрезентативной, как показано на рисунке 13.
2) Проверка загрузки классаСтатистика загрузки классов в основном учитывает всю информацию о классах, загруженную в данный момент программой, что является важными данными, занимаемыми вычислительным метапространством. Слишком много информации о классе загрузки также приведет к занятию большого объема метапространства.В подобных сценариях RPC кэширование информации о классе загрузки может легко вызвать OOM.
3) Проверка объекта на утечкуВо-первых, вводятся три понятия; Неглубокая куча: объем памяти, занимаемый объектом, не имеет ничего общего с содержимым объекта, а только со структурой объекта. Глубокая куча: после того, как объект утилизирован сборщиком мусора, размер памяти, которая может быть фактически освобождена, то есть сумма неглубоких куч (доминирующего дерева) всех объектов, доступ к которым осуществляется через объект. Дерево доминирования: в эталонном графе объекта, если все пути к объекту B проходят через объект A, то считается, что объект A доминирует над объектом B; если объект A является ближайшим доминирующим объектом к объекту B, то объект A считается доминирующим. быть объекта Б. прямой правитель. Согласно стратегии GC, объекты в куче могут иметь только два состояния: одно — это объект, доступный через корень GC, а другой — объект, недостижимый через корень GC. Недоступные объекты будут возвращены сборщиком мусора, и соответствующая память будет возвращена системе. Доступные объекты — это объекты, на которые прямо или косвенно ссылаются пользователи, поэтому утечки объектов направлены на объекты, на которые пользователи косвенно ссылаются, но которые никогда не будут использоваться.Эти объекты не могут быть выпущены, поскольку на них есть ссылки. Утечка объектов не абсолютная, а относительная, точной нормы вообще нет, но ее можно оценить по размеру глубокой кучи объекта. Например, обнаружено, что HashMap хранит 4844 объекта (как показано на рисунке 14), а вычисление мелкой кучи HashMap составляет около 115 КБ, что может показаться несложным; но, вычислив глубокую кучу объект, обнаружено, что он превышает 500 МБ. В этом случае, если HashMap не может быть освобожден, а новые значения ключей продолжают добавляться, память кучи может быть исчерпана, и может произойти OOM.
Об авторе:
Нианву, старший бэкэнд-инженер
В основном отвечает за платформу производительности Java и поддержку JDK, а также проводит углубленные исследования в области проверки дефектов и компиляторов.
Для получения более интересного контента, пожалуйста, обратите внимание на общедоступную учетную запись [OPPO Internet Technology].