Статьи

HotSpot GC Thread Загрузка процессора в Linux

Ноябрь 1, 2018

 



Следующий вопрос проверит ваши знания по сбору мусора и устранению проблем с высокой загрузкой ЦП для приложений Java, работающих на ОС Linux. Этот метод устранения неполадок особенно важен при исследовании чрезмерного использования ГХ и / или ЦП.

Предполагается, что у вас нет доступа к расширенным инструментам мониторинга, таким как Compuware dynaTrace или даже JVisualVM. Будущие руководства с использованием таких инструментов будут представлены в будущем, но, пожалуйста, убедитесь, что вы сначала освоили базовые принципы устранения неполадок.

Вопрос:

Как вы можете отслеживать и вычислять, сколько CPU% каждый из потоков сборки мусора (GC) Oracle HotSpot или JRockit использует во время выполнения в ОС Linux?

Ответ:

В ОС Linux потоки Java реализованы в виде собственных потоков, в результате чего каждый поток представляет собой отдельный процесс Linux. Это означает , что вы в состоянии контролировать CPU% любой Java нити , созданной HotSpot JVM с помощью
верхней -H
команды (темы переключаемых зрений).

Тем не менее, в зависимости от политики GC, которую вы используете, и спецификаций вашего сервера, JSM HotSpot & JRockit создаст определенное количество потоков GC, которые будут выполнять молодые и старые космические коллекции. Такие потоки могут быть легко идентифицированы путем создания дампа потока JVM. Как вы можете видеть ниже в нашем примере, JVM Oracle JRockit создала 4 потока GC, обозначенных как «(GC Worker Thread X)».

 ===== FULL THREAD DUMP ===============
Fri Nov 16 19:58:36 2012
BEA JRockit(R) R27.5.0-110-94909-1.5.0_14-20080204-1558-linux-ia32

"Main Thread" id=1 idx=0x4 tid=14911 prio=5 alive, in native, waiting
    -- Waiting for notification on: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock]
    at jrockit/vm/Threads.waitForNotifySignal(JLjava/lang/Object;)Z(Native Method)
    at java/lang/Object.wait(J)V(Native Method)
    at java/lang/Object.wait(Object.java:474)
    at weblogic/t3/srvr/T3Srvr.waitForDeath(T3Srvr.java:730)
    ^-- Lock released while waiting: weblogic/t3/srvr/T3Srvr@0xfd0a4b0[fat lock]
    at weblogic/t3/srvr/T3Srvr.run(T3Srvr.java:380)
    at weblogic/Server.main(Server.java:67)
    at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
    -- end of trace

"(Signal Handler)" id=2 idx=0x8 tid=14920 prio=5 alive, in native, daemon

"(GC Main Thread)" id=3 idx=0xc tid=14921 prio=5 alive, in native, native_waiting, daemon

"(GC Worker Thread 1)" id=? idx=0x10 tid=14922 prio=5 alive, in native, daemon

"(GC Worker Thread 2)" id=? idx=0x14 tid=14923 prio=5 alive, in native, daemon

"(GC Worker Thread 3)" id=? idx=0x18 tid=14924 prio=5 alive, in native, daemon

"(GC Worker Thread 4)" id=? idx=0x1c tid=14925 prio=5 alive, in native, daemon
………………………
Теперь давайте соединим все эти принципы на простом примере.

Шаг № 1 — Контроль загрузки ЦП потока GC

Первым этапом расследования является мониторинг и определение:

  • Определение родной темы ID для каждого рабочего потока GC показанный через Linux топ -H команды .
  • Определите% ЦП для каждого рабочего потока GC.


Шаг № 2 — Генерация и анализ дампов JVM-потоков

В то же время в Linux top –H создайте 2 или 3 снимка дампа потока JVM с помощью kill -3 <Java PID>.

  • Откройте дамп потока JVM и найдите рабочие потоки GV JVM.
  • Теперь сопоставьте выходные данные «top -H» с данными дампа потока JVM, посмотрев на собственный идентификатор потока (атрибут tid).


Как вы можете видеть в нашем примере, такой анализ позволил нам определить, что все наши рабочие потоки GC использовали около 20% ЦП каждый. Это было связано с большими коллекциями, происходящими в то время. Обратите внимание, что также очень полезно включить verbose: gc, поскольку это позволит вам соотнести такие пики ЦП с второстепенными и основными коллекциями и определить, насколько ваш процесс GC JVM влияет на общую загрузку ЦП сервера.

35
Share: