Следующий вопрос проверит ваши знания по сбору мусора и устранению проблем с высокой загрузкой ЦП для приложений Java, работающих на ОС Linux. Этот метод устранения неполадок особенно важен при исследовании чрезмерного использования ГХ и / или ЦП. Предполагается, что у вас нет доступа к расширенным инструментам мониторинга, таким как Compuware dynaTrace или даже JVisualVM. Будущие руководства с использованием таких инструментов будут представлены в будущем, но, пожалуйста, убедитесь, что вы сначала освоили базовые принципы устранения неполадок.
Вопрос:
Как вы можете отслеживать и вычислять, сколько CPU% каждый из потоков сборки мусора (GC) Oracle HotSpot или JRockit использует во время выполнения в ОС Linux?
Ответ:
В ОС Linux потоки Java реализованы в виде собственных потоков, в результате чего каждый поток представляет собой отдельный процесс Linux. Это означает, что вы можете отслеживать% ЦП любого потока Java, созданного виртуальной виртуальной машиной HotSpot, с помощью команды top -H (представление переключения потоков).
Тем не менее, в зависимости от политики GC, которую вы используете, и спецификаций вашего сервера, JSM HotSpot & JRockit создаст определенное количество потоков GC, которые будут выполнять молодые и старые космические коллекции. Такие потоки могут быть легко идентифицированы путем создания дампа потока JVM. Как вы можете видеть ниже в нашем примере, JVM Oracle JRockit создала 4 потока GC, обозначенных как «(GC Worker Thread X)».
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
|
===== FULL THREAD DUMP ===============Fri Nov 16 19:58:36 2012BEA 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
Первым этапом расследования является мониторинг и определение:
- Определите собственный идентификатор потока для каждого рабочего потока GC, показанный с помощью команды Linux top –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 влияет на общую загрузку ЦП сервера.