Открыть меню
Открыть персональное меню
Вы не представились системе
Your IP address will be publicly visible if you make any edits.

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

Материал из Документация АппОптима
Нет описания правки
Нет описания правки
 
(не показана 1 промежуточная версия 1 участника)
Строка 1: Строка 1:
'''''[[Применение АппОптима]] / Профилирование и оптимизация / Непрерывный анализ потоков'''''
Многопоточные архитектуры легко масштабируются, поскольку распределение работы позволяет процессорам оставаться активными и продолжать выполнять код. Однако, когда системам необходимо координировать работу в нескольких потоках, блокировки увеличиваются, и может произойти сокращение выполнения кода.
Многопоточные архитектуры легко масштабируются, поскольку распределение работы позволяет процессорам оставаться активными и продолжать выполнять код. Однако, когда системам необходимо координировать работу в нескольких потоках, блокировки увеличиваются, и может произойти сокращение выполнения кода.


В Ключ-АСТРОМ такое поведение автоматически и непрерывно обнаруживается ЕдинымАгентом. Благодаря непрерывному анализу потоков данные постоянно доступны, с историческим контекстом, и их не нужно запускать при возникновении проблемы. Вы можете получать оповещения о тенденциях, анализировать дампы потоков и напрямую начинать улучшать код, когда и где это необходимо, чтобы предотвратить проблемы.
В АппОптима такое поведение автоматически и непрерывно обнаруживается ЕдинымАгентом. Благодаря непрерывному анализу потоков данные постоянно доступны, с историческим контекстом, и их не нужно запускать при возникновении проблемы. Вы можете получать оповещения о тенденциях, анализировать дампы потоков и напрямую начинать улучшать код, когда и где это необходимо, чтобы предотвратить проблемы.


== Прежде чем начать ==
== Прежде чем начать ==
Строка 49: Строка 51:
В этом примере группа процессов <code>idea*.exe</code> показывает всплеск потребления ЦП. Мы исследуем проблему на странице анализа потоков , начиная с фильтрации списка групп потоков по состоянию потока '''Блокировка'''.
В этом примере группа процессов <code>idea*.exe</code> показывает всплеск потребления ЦП. Мы исследуем проблему на странице анализа потоков , начиная с фильтрации списка групп потоков по состоянию потока '''Блокировка'''.


[[Файл:184.png|граница]]
[[Файл:184.png|граница|1158x1158пкс]]


Мы видим, что система не в плохом состоянии, но все еще есть блокирующее поведение, влияющее на <code>23</code>группы потоков. Мы выбираем первую и наиболее затронутую группу потоков, <code>JobScheduler FJ pool</code>, чтобы продолжить наш анализ.
Мы видим, что система не в плохом состоянии, но все еще есть блокирующее поведение, влияющее на <code>23</code>группы потоков. Мы выбираем первую и наиболее затронутую группу потоков, <code>JobScheduler FJ pool</code>, чтобы продолжить наш анализ.


[[Файл:185.png|граница]]
[[Файл:185.png|граница|1162x1162пкс]]


Для группы потоков <code>JobScheduler FJ pool</code> значительное количество времени (почти половина: <code>46.1%</code>) постоянно тратится на блокировку, и она распределена по <code>15</code>потокам. Это указывает на общую блокировку, влияющую на все эти потоки. Мы хотим избежать такого поведения, поскольку оно ограничивает как скорость, так и возможность увеличения пропускной способности путем добавления ресурсов. В конечном итоге это может привести к состоянию, когда система не сможет обрабатывать больше данных, даже если мы добавим больше оборудования.
Для группы потоков <code>JobScheduler FJ pool</code> значительное количество времени (почти половина: <code>46.1%</code>) постоянно тратится на блокировку, и она распределена по <code>15</code>потокам. Это указывает на общую блокировку, влияющую на все эти потоки. Мы хотим избежать такого поведения, поскольку оно ограничивает как скорость, так и возможность увеличения пропускной способности путем добавления ресурсов. В конечном итоге это может привести к состоянию, когда система не сможет обрабатывать больше данных, даже если мы добавим больше оборудования.
Строка 68: Строка 70:
В этом примере группа процессов <code>doaks-prod1-eastus-cassandra</code> тратит часть времени <code>9.97%</code> на выполнение кода.
В этом примере группа процессов <code>doaks-prod1-eastus-cassandra</code> тратит часть времени <code>9.97%</code> на выполнение кода.


[[Файл:187.png|граница]]
[[Файл:187.png|граница|1317x1317пкс]]


Мы выбираем время ЦП , чтобы понять, как поведение влияет на потребление ЦП. Из диаграммы мы видим, что группа потоков <code>MutationStage</code> вносит наибольший вклад. Из таблицы ниже мы узнаем, что она тратит <code>1.6 d</code> в Оценочном времени ЦП и <code>3.55%</code> в Общей трассировке в выполнении кода.
Мы выбираем время ЦП , чтобы понять, как поведение влияет на потребление ЦП. Из диаграммы мы видим, что группа потоков <code>MutationStage</code> вносит наибольший вклад. Из таблицы ниже мы узнаем, что она тратит <code>1.6 d</code> в Оценочном времени ЦП и <code>3.55%</code> в Общей трассировке в выполнении кода.


[[Файл:188.png|граница]]
[[Файл:188.png|граница|1331x1331пкс]]


Мы хотим определить, какой код выполняется и как он влияет на потребление ЦП. После выбора имени группы потоков (<code>MutationStage</code>), первый поток в списке внизу страницы является самым затратным (<code>MutationStage-2</code>).
Мы хотим определить, какой код выполняется и как он влияет на потребление ЦП. После выбора имени группы потоков (<code>MutationStage</code>), первый поток в списке внизу страницы является самым затратным (<code>MutationStage-2</code>).


[[Файл:189.png|граница]]
[[Файл:189.png|граница|1345x1345пкс]]


Чтобы увидеть список точек доступа, выбираем '''Дополнительно ( … ) > Хотспоты метода''' для <code>MutationStage-2</code>.
Чтобы увидеть список точек доступа, выбираем '''Дополнительно ( … ) > Хотспоты метода''' для <code>MutationStage-2</code>.


[[Файл:190.png|граница]]
[[Файл:190.png|граница|1322x1322пкс]]


Теперь мы видим, что <code>Unsafe.unpark</code> это способствует <code>30.1%</code> выполнению кода и является хорошим показателем для оптимизации.
Теперь мы видим, что <code>Unsafe.unpark</code> это способствует <code>30.1%</code> выполнению кода и является хорошим показателем для оптимизации.

Текущая версия от 14:37, 26 декабря 2024

Применение АппОптима / Профилирование и оптимизация / Непрерывный анализ потоков

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

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

Прежде чем начать

Чтобы начать использовать непрерывный анализ потока

  1. Перейдите в Настройки > Предпочтения > Функции ЕдиногоАгента .
  2. Найдите и включите следующие функции ЕдиногоАгента для технологии, которую вы хотите отслеживать:
Технология мониторинга Функции OneAgent для включения
Java Непрерывный анализ потока
Node.js Мониторинг рабочих потоков Node.js

Предварительная загрузка модуля кода Node.js

Поддерживаемые версии Java

Из-за известной проблемы с Java 11 непрерывный анализ потоков JVM доступен только для Java 8 и Java 17+ (в зависимости от поддерживаемых версий ). Потоки приложений и агентов остаются неизменными.

Анализ данных

Чтобы начать анализировать дампы потоков

  1. Перейдите в раздел Профилирование > Непрерывное профилирование ЦП.
  2. Для группы процессов, которую вы хотите проанализировать, выберите Дополнительно ( … ) > Потоки.
  3. На странице анализа темы вы можете:
    • Проанализируйте распределение потоков по состояниям потоков или по предполагаемому времени ЦП.
    • Включайте или исключайте данные об ожидающих потоках в любое время, установив соответствующий флажок.
    • Фильтровать данные
      • По типу запроса. Выберите Фильтр запросов > Тип и выберите вариант.
      • По запросу имя группы потоков. Выберите имя группы потоков. Сегментация групп потоков учитывает тот факт, что они обычно выполняют разные функции, и дает вам быстрые средства для идентификации потребителей ЦП.
    • Проанализируйте горячие точки метода группы потоков. В столбце Действия группы потоков выберите Дополнительно ( … ) > Хотспоты метода.

Случаи использования

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

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

Пример: блокировки препятствуют масштабируемости приложения

Определите проблемы масштабируемости

В этом примере группа процессов idea*.exe показывает всплеск потребления ЦП. Мы исследуем проблему на странице анализа потоков , начиная с фильтрации списка групп потоков по состоянию потока Блокировка.

184.png

Мы видим, что система не в плохом состоянии, но все еще есть блокирующее поведение, влияющее на 23группы потоков. Мы выбираем первую и наиболее затронутую группу потоков, JobScheduler FJ pool, чтобы продолжить наш анализ.

185.png

Для группы потоков JobScheduler FJ pool значительное количество времени (почти половина: 46.1%) постоянно тратится на блокировку, и она распределена по 15потокам. Это указывает на общую блокировку, влияющую на все эти потоки. Мы хотим избежать такого поведения, поскольку оно ограничивает как скорость, так и возможность увеличения пропускной способности путем добавления ресурсов. В конечном итоге это может привести к состоянию, когда система не сможет обрабатывать больше данных, даже если мы добавим больше оборудования.

Чтобы добраться до первопричины, выбираем Дополнительно ( … ) > Методы вызова.

186.png

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

Пример: Большое количество потоков приводит к чрезмерному использованию ресурсов.

Определите группы потоков, интенсивно использующие ЦП

В этом примере группа процессов doaks-prod1-eastus-cassandra тратит часть времени 9.97% на выполнение кода.

187.png

Мы выбираем время ЦП , чтобы понять, как поведение влияет на потребление ЦП. Из диаграммы мы видим, что группа потоков MutationStage вносит наибольший вклад. Из таблицы ниже мы узнаем, что она тратит 1.6 d в Оценочном времени ЦП и 3.55% в Общей трассировке в выполнении кода.

188.png

Мы хотим определить, какой код выполняется и как он влияет на потребление ЦП. После выбора имени группы потоков (MutationStage), первый поток в списке внизу страницы является самым затратным (MutationStage-2).

189.png

Чтобы увидеть список точек доступа, выбираем Дополнительно ( … ) > Хотспоты метода для MutationStage-2.

190.png

Теперь мы видим, что Unsafe.unpark это способствует 30.1% выполнению кода и является хорошим показателем для оптимизации.