Непрерывный анализ потоков: различия между версиями
(Создана пустая страница) |
ENetrebin (обсуждение | вклад) |
||
(не показана 1 промежуточная версия 1 участника) | |||
Строка 1: | Строка 1: | ||
'''''[[Применение Ключ-АСТРОМ]] / [[Применение Ключ-АСТРОМ#.D0.9F.D1.80.D0.BE.D1.84.D0.B8.D0.BB.D0.B8.D1.80.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D0.B5%20.D0.B8%20.D0.BE.D0.BF.D1.82.D0.B8.D0.BC.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D1.8F|Профилирование и оптимизация]] / Непрерывный анализ потоков''''' | |||
Многопоточные архитектуры легко масштабируются, поскольку распределение работы позволяет процессорам оставаться активными и продолжать выполнять код. Однако, когда системам необходимо координировать работу в нескольких потоках, блокировки увеличиваются, и может произойти сокращение выполнения кода. | |||
В Ключ-АСТРОМ такое поведение автоматически и непрерывно обнаруживается ЕдинымАгентом. Благодаря непрерывному анализу потоков данные постоянно доступны, с историческим контекстом, и их не нужно запускать при возникновении проблемы. Вы можете получать оповещения о тенденциях, анализировать дампы потоков и напрямую начинать улучшать код, когда и где это необходимо, чтобы предотвратить проблемы. | |||
== Прежде чем начать == | |||
Чтобы начать использовать непрерывный анализ потока | |||
# Перейдите в '''Настройки > Предпочтения > Функции ЕдиногоАгента''' . | |||
# Найдите и включите следующие функции ЕдиногоАгента для технологии, которую вы хотите отслеживать: | |||
{| class="wikitable" | |||
!Технология мониторинга | |||
!Функции OneAgent для включения | |||
|- | |||
|Java | |||
|Непрерывный анализ потока | |||
|- | |||
|Node.js | |||
|Мониторинг рабочих потоков Node.js | |||
Предварительная загрузка модуля кода Node.js | |||
|} | |||
Поддерживаемые версии Java | |||
Из-за известной проблемы с Java 11 непрерывный анализ потоков JVM доступен только для Java 8 и Java 17+ (в зависимости от поддерживаемых версий ). Потоки приложений и агентов остаются неизменными. | |||
== Анализ данных == | |||
Чтобы начать анализировать дампы потоков | |||
# Перейдите в раздел '''Профилирование > Непрерывное профилирование ЦП'''. | |||
# Для группы процессов, которую вы хотите проанализировать, выберите '''Дополнительно ( … ) > Потоки'''. | |||
# На странице анализа темы вы можете: | |||
#* Проанализируйте распределение потоков по состояниям потоков или по предполагаемому времени ЦП. | |||
#* Включайте или исключайте данные об ожидающих потоках в любое время, установив соответствующий флажок. | |||
#* Фильтровать данные | |||
#** По типу запроса. Выберите '''Фильтр запросов > Тип''' и выберите вариант. | |||
#** По запросу имя группы потоков. Выберите имя группы потоков. Сегментация групп потоков учитывает тот факт, что они обычно выполняют разные функции, и дает вам быстрые средства для идентификации потребителей ЦП. | |||
#* Проанализируйте горячие точки метода группы потоков. В столбце '''Действия''' группы потоков выберите '''Дополнительно ( … ) > Хотспоты метода'''. | |||
== Случаи использования == | |||
Потоки являются источником масштабируемости, поскольку они позволяют вашим приложениям выполнять несколько задач одновременно. В определенных ситуациях это может стать источником проблем производительности. Например: | |||
* В системах с высокой нагрузкой могут возникнуть проблемы с блокировкой потоков, что не позволит масштабировать приложение . | |||
* Если количество активных потоков слишком велико, ресурсы ЦП могут расходоваться впустую из-за чрезмерной загрузки или из-за того, что операционным системам приходится планировать тысячи потоков на ограниченном наборе ядер. | |||
=== Пример: блокировки препятствуют масштабируемости приложения === | |||
==== Определите проблемы масштабируемости ==== | |||
В этом примере группа процессов <code>idea*.exe</code> показывает всплеск потребления ЦП. Мы исследуем проблему на странице анализа потоков , начиная с фильтрации списка групп потоков по состоянию потока '''Блокировка'''. | |||
[[Файл:184.png|граница]] | |||
Мы видим, что система не в плохом состоянии, но все еще есть блокирующее поведение, влияющее на <code>23</code>группы потоков. Мы выбираем первую и наиболее затронутую группу потоков, <code>JobScheduler FJ pool</code>, чтобы продолжить наш анализ. | |||
[[Файл:185.png|граница]] | |||
Для группы потоков <code>JobScheduler FJ pool</code> значительное количество времени (почти половина: <code>46.1%</code>) постоянно тратится на блокировку, и она распределена по <code>15</code>потокам. Это указывает на общую блокировку, влияющую на все эти потоки. Мы хотим избежать такого поведения, поскольку оно ограничивает как скорость, так и возможность увеличения пропускной способности путем добавления ресурсов. В конечном итоге это может привести к состоянию, когда система не сможет обрабатывать больше данных, даже если мы добавим больше оборудования. | |||
Чтобы добраться до первопричины, выбираем '''Дополнительно ( … ) > Методы вызова'''. | |||
[[Файл:186.png|граница]] | |||
На основе полученной информации мы можем локализовать проблему блокировки и протестировать различные способы написания кода для повышения его производительности. | |||
=== Пример: Большое количество потоков приводит к чрезмерному использованию ресурсов. === | |||
==== Определите группы потоков, интенсивно использующие ЦП ==== | |||
В этом примере группа процессов <code>doaks-prod1-eastus-cassandra</code> тратит часть времени <code>9.97%</code> на выполнение кода. | |||
[[Файл:187.png|граница]] | |||
Мы выбираем время ЦП , чтобы понять, как поведение влияет на потребление ЦП. Из диаграммы мы видим, что группа потоков <code>MutationStage</code> вносит наибольший вклад. Из таблицы ниже мы узнаем, что она тратит <code>1.6 d</code> в Оценочном времени ЦП и <code>3.55%</code> в Общей трассировке в выполнении кода. | |||
[[Файл:188.png|граница]] | |||
Мы хотим определить, какой код выполняется и как он влияет на потребление ЦП. После выбора имени группы потоков (<code>MutationStage</code>), первый поток в списке внизу страницы является самым затратным (<code>MutationStage-2</code>). | |||
[[Файл:189.png|граница]] | |||
Чтобы увидеть список точек доступа, выбираем '''Дополнительно ( … ) > Хотспоты метода''' для <code>MutationStage-2</code>. | |||
[[Файл:190.png|граница]] | |||
Теперь мы видим, что <code>Unsafe.unpark</code> это способствует <code>30.1%</code> выполнению кода и является хорошим показателем для оптимизации. |
Текущая версия на 14:27, 13 сентября 2024
Применение Ключ-АСТРОМ / Профилирование и оптимизация / Непрерывный анализ потоков
Многопоточные архитектуры легко масштабируются, поскольку распределение работы позволяет процессорам оставаться активными и продолжать выполнять код. Однако, когда системам необходимо координировать работу в нескольких потоках, блокировки увеличиваются, и может произойти сокращение выполнения кода.
В Ключ-АСТРОМ такое поведение автоматически и непрерывно обнаруживается ЕдинымАгентом. Благодаря непрерывному анализу потоков данные постоянно доступны, с историческим контекстом, и их не нужно запускать при возникновении проблемы. Вы можете получать оповещения о тенденциях, анализировать дампы потоков и напрямую начинать улучшать код, когда и где это необходимо, чтобы предотвратить проблемы.
Прежде чем начать
Чтобы начать использовать непрерывный анализ потока
- Перейдите в Настройки > Предпочтения > Функции ЕдиногоАгента .
- Найдите и включите следующие функции ЕдиногоАгента для технологии, которую вы хотите отслеживать:
Технология мониторинга | Функции OneAgent для включения |
---|---|
Java | Непрерывный анализ потока |
Node.js | Мониторинг рабочих потоков Node.js
Предварительная загрузка модуля кода Node.js |
Поддерживаемые версии Java
Из-за известной проблемы с Java 11 непрерывный анализ потоков JVM доступен только для Java 8 и Java 17+ (в зависимости от поддерживаемых версий ). Потоки приложений и агентов остаются неизменными.
Анализ данных
Чтобы начать анализировать дампы потоков
- Перейдите в раздел Профилирование > Непрерывное профилирование ЦП.
- Для группы процессов, которую вы хотите проанализировать, выберите Дополнительно ( … ) > Потоки.
- На странице анализа темы вы можете:
- Проанализируйте распределение потоков по состояниям потоков или по предполагаемому времени ЦП.
- Включайте или исключайте данные об ожидающих потоках в любое время, установив соответствующий флажок.
- Фильтровать данные
- По типу запроса. Выберите Фильтр запросов > Тип и выберите вариант.
- По запросу имя группы потоков. Выберите имя группы потоков. Сегментация групп потоков учитывает тот факт, что они обычно выполняют разные функции, и дает вам быстрые средства для идентификации потребителей ЦП.
- Проанализируйте горячие точки метода группы потоков. В столбце Действия группы потоков выберите Дополнительно ( … ) > Хотспоты метода.
Случаи использования
Потоки являются источником масштабируемости, поскольку они позволяют вашим приложениям выполнять несколько задач одновременно. В определенных ситуациях это может стать источником проблем производительности. Например:
- В системах с высокой нагрузкой могут возникнуть проблемы с блокировкой потоков, что не позволит масштабировать приложение .
- Если количество активных потоков слишком велико, ресурсы ЦП могут расходоваться впустую из-за чрезмерной загрузки или из-за того, что операционным системам приходится планировать тысячи потоков на ограниченном наборе ядер.
Пример: блокировки препятствуют масштабируемости приложения
Определите проблемы масштабируемости
В этом примере группа процессов idea*.exe
показывает всплеск потребления ЦП. Мы исследуем проблему на странице анализа потоков , начиная с фильтрации списка групп потоков по состоянию потока Блокировка.
Мы видим, что система не в плохом состоянии, но все еще есть блокирующее поведение, влияющее на 23
группы потоков. Мы выбираем первую и наиболее затронутую группу потоков, JobScheduler FJ pool
, чтобы продолжить наш анализ.
Для группы потоков JobScheduler FJ pool
значительное количество времени (почти половина: 46.1%
) постоянно тратится на блокировку, и она распределена по 15
потокам. Это указывает на общую блокировку, влияющую на все эти потоки. Мы хотим избежать такого поведения, поскольку оно ограничивает как скорость, так и возможность увеличения пропускной способности путем добавления ресурсов. В конечном итоге это может привести к состоянию, когда система не сможет обрабатывать больше данных, даже если мы добавим больше оборудования.
Чтобы добраться до первопричины, выбираем Дополнительно ( … ) > Методы вызова.
На основе полученной информации мы можем локализовать проблему блокировки и протестировать различные способы написания кода для повышения его производительности.
Пример: Большое количество потоков приводит к чрезмерному использованию ресурсов.
Определите группы потоков, интенсивно использующие ЦП
В этом примере группа процессов doaks-prod1-eastus-cassandra
тратит часть времени 9.97%
на выполнение кода.
Мы выбираем время ЦП , чтобы понять, как поведение влияет на потребление ЦП. Из диаграммы мы видим, что группа потоков MutationStage
вносит наибольший вклад. Из таблицы ниже мы узнаем, что она тратит 1.6 d
в Оценочном времени ЦП и 3.55%
в Общей трассировке в выполнении кода.
Мы хотим определить, какой код выполняется и как он влияет на потребление ЦП. После выбора имени группы потоков (MutationStage
), первый поток в списке внизу страницы является самым затратным (MutationStage-2
).
Чтобы увидеть список точек доступа, выбираем Дополнительно ( … ) > Хотспоты метода для MutationStage-2
.
Теперь мы видим, что Unsafe.unpark
это способствует 30.1%
выполнению кода и является хорошим показателем для оптимизации.