Накладные расходы асинхронного профилировщика на Zing

Question

Наша команда отслеживает задержку нашего приложения с помощью HdrHistograms. Когда я прикрепляю к нему асинхронный профилировщик, все процентили резко возрастают.

ОС: Red Hat Enterprise Linux версии 8.1 (Ootpa)

JVM: 11.0.8-zing_20.08.2.0-b2-product-linux-X86_64

Вот что произойдет, если я прикреплю профилировщик с флагами -i 1000 -t:

Вот что произойдет, если я прикреплю профилировщик с флагами -i 100000 -t:

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

1. Есть ли другие способы уменьшить накладные расходы на профилирование, кроме уменьшения частоты дискретизации? Может есть какие-то волшебные флаги ядра /JVM?
2. Эти накладные расходы существенно искажают сам профиль?

Спасибо

Answer 1

Интервал профилирования выражается в наносекундах. Вы можете явно указать единицы измерения, например -i 10ms. В твоем случае, -i 1000означает 1000 наносекунд, что не является разумным интервалом выборки: процесс будет просто выполнять непрерывную выборку вместо полезной работы - и, конечно, профиль результата не будет отражать реалистичную картину. Начните с интервала по умолчанию (10 мс) и уменьшайте его только в случае крайней необходимости.

В этом ответе я объяснил разумный диапазон:

Что касается интервала профилирования, то 10 нс - это примерно 20-50 команд процессора. С такой скоростью брать пробы буквально невозможно. Процесс не будет делать ничего, кроме как проводить все время внутри профилировщика.

Интервал выборки по умолчанию в режиме процессора составляет 10 мс. Этот выбор достаточно хорош для профилирования в производственной среде: для среднего приложения накладные расходы на профилирование будут незначительными, в то время как количества выборок будет достаточно для получения значимого профиля.

Интервал в 1 мс обычно подходит для тестов и для профилирования реальных приложений за короткий период времени. Более низкие интервалы редко бывают полезными - возможно, только для захвата профиля короткого исполняемого фрагмента кода.