Общее время, на которое потоки приложения были остановлены

Сейфпойнт
Многие из нас знают, что JVM приостанавливает все приложение для сборки мусора. Но есть и другие причины, по которым JVM приостанавливает работу приложения. Для некоторых Операции с ВМопределенный JVMTI-операцииа также JIT-действия JVM приостанавливает приложение. Вот несколько таких случаев:

  1. Выгрузка классов
  2. Перемещение объектов для исправления дефрагментации памяти
  3. Деоптимизация кода
  4. Очистка кеша кода
  5. Переопределение класса (например, горячая замена или контрольно-измерительные приборы)
  6. Предвзятая отмена блокировки
    :
    :

Чтобы приостановить все потоки приложения, необходимо безопасно остановить их. Точка, в которой потоки приложения безопасно останавливаются, называется «безопасной точкой». Подходящее имя, не так ли?

Вы можете узнать, сколько времени потоки приложений останавливаются в Safepoint, передав JVM следующие аргументы:

-XX:+PrintGCApplicationStoppedTime -XX:+PrintGCApplicationConcurrentTime

Когда вы передаете вышеуказанные аргументы, вы увидите следующий вывод, который будет напечатан в журналах сборки мусора:

16.827: Total time for which application threads were stopped: 0.0010093 seconds, Stopping threads took: 0.0001973 seconds 

В приведенном выше утверждении в основном говорится, что через 16,827 секунд с момента запуска приложения потоки приложения были остановлены на 1 миллисекунду (т.е. 0,0010093 секунды), а количество времени, необходимое для остановки потоков, составило: 197,3 микросекунды (т.е. 0,0001973 секунды). Это время паузы является приемлемым. Но иногда мы видели случаи, когда потоки приложений останавливались на несколько секунд. Пример:

4279.344: Total time for which application threads were stopped: 12.4744981 seconds, Stopping threads took: 12.3604520 seconds

Здесь вы можете заметить, что потоки приложения были остановлены на 12,47 секунды, а для остановки запущенных потоков потребовалось 12,36 секунды. Это очень большое время паузы. (Примечание: может быть сложно отслеживать продолжительность точки сохранения, особенно когда вы анализируете тысячи/миллионы операторов журнала. Именно тогда инструменты анализа журнала сборки мусора, такие как GCeasy пригодится. Инструмент GCeasy улавливает и сообщает о точках сохранения, которые приостанавливаются на длительный срок.)

Теперь мы научились измерять длительность точки сохранения. Следующим шагом будет изучение причин, вызывающих срабатывание этих точек безопасности.

-XX:+PrintSafepointStatistics  -XX:PrintSafepointStatisticsCount=1

Когда вы передаете приведенные выше аргументы JVM своему приложению, причины, вызывающие создание точек сохранения, будут указаны в журналах GC. Ниже вывод будет напечатан в журналах сборки мусора:

вмоп[threads: total initially_running wait_to_block] [time: spin block sync cleanup vmop] page_trap_count

7044.693: RevokeBias [ 423 2 4 ] [ 11608 0 11611 3 98 ] 2

Теперь попробуем понять это утверждение:

7044.693 — количество секунд с момента запуска JVM, в течение которого выполнялась эта операция сохранения.

RevokeBias – вмоп – операция ВМ, для которой потоки перемещаются в эту точку сохранения.

423 – общий – Общее количество потоков, остановленных в точке сохранения

2 – Initial_running – Количество потоков, которые повлияли на время «вращения», поясняется в разделе ниже.

4 – ждать_до_блока – Количество потоков, которые способствовали времени «блокировки», поясняется в разделе ниже.

Следующая часть показывает разбивку времени в миллисекундах на разных этапах достижения безопасной точки.

11608 – вращение – время, которое потребовалось всем вращающимся/исполняющим потокам для достижения точки сохранения (в миллисекундах)

0 – блокировать – время, которое потребовалось всем заблокированным потокам для достижения точки сохранения (в миллисекундах)

11611 – синхронизировать – общее время, которое потребовалось всем потокам для достижения точки сохранения (в миллисекундах)

3 – уборка – время, затрачиваемое на внутреннюю очистку ВМ (в миллисекундах)

98 – вмоп – время, проведенное в самой операции (в данном случае RevokeBias).

2 – page_trap_count — Количество ловушек страницы

нет работы с вм
Если вы видите, что в поле «vmop» будет напечатано «нет операции с виртуальной машиной», это называется «гарантированная точка безопасности». Он запускается самой средой выполнения JVM для обработки всех операций в очереди, которые не являются срочными. Им можно управлять, передав аргумент JVM «GuaranteedSafepointInterval»:

-XX:GuaranteedSafepointInterval=300000

Эта команда предписывает среде выполнения гарантировать точку сохранения только каждые 300 секунд (т. е. 5 минут).

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *