Непрерывный анализ потоков - История изменений

IKuznetsov в 08:27, 6 января 2025

2025-01-06T08:27:50Z

← Предыдущая версия		Версия от 08:27, 6 января 2025
Строка 1:		Строка 1:
	'''''[[Применение АппОптима]] / Профилирование и оптимизация / Непрерывный анализ потоков'''''		'''''[[Применение АппОптима]] / [[Профилирование и оптимизация]] / Непрерывный анализ потоков'''''

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

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

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

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

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

	[[Файл:186.png\|граница]]		[[Файл:186.png\|граница\|1096x1096пкс]]

	На основе полученной информации мы можем локализовать проблему блокировки и протестировать различные способы написания кода для повышения его производительности.		На основе полученной информации мы можем локализовать проблему блокировки и протестировать различные способы написания кода для повышения его производительности.
Строка 70:		Строка 70:
	В этом примере группа процессов <code>doaks-prod1-eastus-cassandra</code> тратит часть времени <code>9.97%</code> на выполнение кода.		В этом примере группа процессов <code>doaks-prod1-eastus-cassandra</code> тратит часть времени <code>9.97%</code> на выполнение кода.

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

	Мы выбираем время ЦП , чтобы понять, как поведение влияет на потребление ЦП. Из диаграммы мы видим, что группа потоков <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\|граница\|~~1331x1331пкс~~]]		[[Файл:188.png\|граница\|1092x1092px]]

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

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

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

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

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

IKuznetsov в 14:37, 26 декабря 2024

2024-12-26T14:37:20Z

← Предыдущая версия		Версия от 14:37, 26 декабря 2024
Строка 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\|Профилирование и оптимизация]] / Непрерывный анализ потоков'''''		'''''[[Применение АппОптима]] / Профилирование и оптимизация / Непрерывный анализ потоков'''''

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

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

	== Прежде чем начать ==		== Прежде чем начать ==
Строка 51:		Строка 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>потокам. Это указывает на общую блокировку, влияющую на все эти потоки. Мы хотим избежать такого поведения, поскольку оно ограничивает как скорость, так и возможность увеличения пропускной способности путем добавления ресурсов. В конечном итоге это может привести к состоянию, когда система не сможет обрабатывать больше данных, даже если мы добавим больше оборудования.
Строка 70:		Строка 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> выполнению кода и является хорошим показателем для оптимизации.

ENetrebin в 14:27, 13 сентября 2024

2024-09-13T14:27:00Z

← Предыдущая версия		Версия от 14:27, 13 сентября 2024
Строка 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\|Профилирование и оптимизация]] / Непрерывный анализ потоков'''''

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

IKuznetsov в 20:55, 1 августа 2024

2024-08-01T20:55:02Z

← Предыдущая версия	Версия от 20:55, 1 августа 2024
Строка 1:	Строка 1:
		Многопоточные архитектуры легко масштабируются, поскольку распределение работы позволяет процессорам оставаться активными и продолжать выполнять код. Однако, когда системам необходимо координировать работу в нескольких потоках, блокировки увеличиваются, и может произойти сокращение выполнения кода.

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

		== Прежде чем начать ==
		Чтобы начать использовать непрерывный анализ потока

		# Перейдите в '''Настройки > Предпочтения > Функции ЕдиногоАгента''' .
		# Найдите и включите следующие функции ЕдиногоАгента для технологии, которую вы хотите отслеживать:

		{\| 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> выполнению кода и является хорошим показателем для оптимизации.

IKuznetsov: Создана пустая страница

2024-08-01T14:26:10Z

Создана пустая страница

Новая страница