Статьи

JRockit — JRCMD полезные команды

Я использую JRockit много лет 2007. Я нахожу это медленнее, чем Hotspot, но он всегда был лучше в диагностике и анализе проблем. С прошлого лета я работаю в качестве международного поставщика телекоммуникационных систем. Мы разрабатываем и внедряем различные продукты для операторов связи на платформе конвергентной связи HP OpenCall. Я фанат Open Source и Free Software, но эта платформа работает « только » с JRockit VM . Мы настроили его на низкие задержки и работали очень круто, но мы столкнулись с различными проблемами, где JRockit очень помог нам в устранении неполадок.

Я опишу здесь несколько полезных команд JRCMD . JRCMD — это небольшой инструмент командной строки, который можно использовать для взаимодействия с работающим экземпляром JRockit.

Резюме:

  1. Получить дамп потока
  2. Использование памяти
  3. Анализ памяти кучи для каждого класса
  4. Состояние В.М.
  5. Создать запись полета
  6. Произведите свалку в кучу

Подробности:

1) Получить дамп потока $> jrcmd <pid> print_threads [nativestack = true]

Это обычный обработчик SIGQUIT, который печатает все стеки потоков. Вы также можете получить поток, используя классический способ: « $> kill -3 <pid> «

В любом случае вы получите дамп потока:

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
===== FULL THREAD DUMP ===============
 Thu Jun 21 11:38:19 2012
 Oracle JRockit(R) R28.1.4-7-144370-1.6.0_26-20110617-2130-linux-ia32
'http-172.18.57.4-8080-58' id=46791 idx=0x4 tid=17680 prio=5 alive, waiting, native_blocked, daemon
 -- Waiting for notification on: org/apache/tomcat/util/net/JIoEndpoint$Worker@0x5eef4588[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:485)
 at org/apache/tomcat/util/net/JIoEndpoint$Worker.await(JIoEndpoint.java:415)
 ^-- Lock released while waiting: org/apache/tomcat/util/net/JIoEndpoint$Worker@0x5eef4588[fat lock]
 at org/apache/tomcat/util/net/JIoEndpoint$Worker.run(JIoEndpoint.java:441)
 at java/lang/Thread.run(Thread.java:662)[optimized]
 at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
 -- end of trace
'(Signal Handler)' id=2 idx=0x8 tid=21213 prio=5 alive, native_blocked, daemon
'(OC Main Thread)' id=3 idx=0xc tid=21214 prio=5 alive, native_waiting, daemon
'(GC Worker Thread 1)' id=? idx=0x10 tid=21215 prio=5 alive, daemon
'(GC Worker Thread 2)' id=? idx=0x14 tid=21216 prio=5 alive, daemon
'(Code Generation Thread 1)' id=4 idx=0x18 tid=21217 prio=5 alive, native_waiting, daemon
'(Code Optimization Thread 1)' id=5 idx=0x1c tid=21218 prio=10 alive, native_waiting, daemon
'(Code Optimization Thread 2)' id=6 idx=0x20 tid=21219 prio=10 alive, native_waiting, daemon
'(VM Periodic Task)' id=7 idx=0x24 tid=21220 prio=10 alive, native_blocked, daemon
'Finalizer' id=8 idx=0x28 tid=21221 prio=8 alive, native_waiting, daemon
 at jrockit/memory/Finalizer.waitForFinalizees(J[Ljava/lang/Object;)I(Native Method)
 at jrockit/memory/Finalizer.access$700(Finalizer.java:12)[optimized]
 at jrockit/memory/Finalizer$4.run(Finalizer.java:189)
 at java/lang/Thread.run(Thread.java:662)
 at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
 -- end of trace
'Reference Handler' id=9 idx=0x2c tid=21222 prio=10 alive, native_waiting, daemon
 at java/lang/ref/Reference.waitForActivatedQueue(J)Ljava/lang/ref/Reference;(Native Method)
 at java/lang/ref/Reference.access$100(Reference.java:11)
 at java/lang/ref/Reference$ReferenceHandler.run(Reference.java:82)
 at jrockit/vm/RNI.c2java(IIIII)V(Native Method)
 -- end of trace
...
...

2) Использование памяти $> jrcmd <pid> print_memusage

Эта команда может помочь вам с ошибками нехватки памяти. Он анализирует (в итоге) память, выделенную процессом Java (включая собственный код). Столбцы: а) имя пространства памяти; б) объем памяти, выделенный для этого пространства; в) дополнительные сведения. Пример прогона следующий:

01
02
03
04
05
06
07
08
09
10
Total mapped                  2110560KB           (reserved=6044KB)
-              Java heap      1572864KB           (reserved=0KB)
-              GC tables        52620KB         
-          Thread stacks        55060KB           (#threads=306)
-          Compiled code        23872KB           (used=21690KB)
-               Internal          776KB         
-                     OS        23368KB         
-                  Other       257328KB         
-        Java class data       123648KB           (malloced=123375KB #169700 in 29996 classes)
- Native memory tracking         1024KB           (malloced=296KB #8)

3) Анализ памяти кучи для каждого класса $> jrcmd <pid> print_object_summary

Печатает сведения обо всех экземплярах в куче для каждого класса вместе с дифференциальным значением того, как изменилось использование памяти. Столбцы: a) Процент кучи, занимаемой объектами этого класса, b) Общий размер, занимаемый экземплярами определенного класса, c) Количество экземпляров определенного класса, d) Изменение размера с первого вызова эта команда, д) Полное имя класса. Проверьте следующий пример, где у нас может быть проблема с объектами класса «org / adrianos / MyDTO»:

01
02
03
04
05
06
07
08
09
10
11
12
13
--------- Detailed Heap Statistics: ---------
61.1% 939735k  6772960 +939735k [C
16.4% 252243k 10762404 +252243k java/lang/String
 7.0% 107516k  3947228 +107516k [Ljava/lang/String;
 4.5% 69265k   369180 +69265k [Ljava/lang/Object;
 1.6% 24127k   205889 +24127k org/adrianos/MyDTO
 1.3% 19486k  1247140 +19486k java/lang/Long
 1.0% 15551k    26621 +15551k [B
 0.6% 8871k     9700  +8871k [I
 0.6% 8710k   103896  +8710k [Ljava/util/HashMap$Entry;
     1537175kB total ---
 
--------- End of Detailed Heap Statistics ---

4) Состояние виртуальной машины $> jrcmd <pid> print_vm_state

Эта команда создает вывод, похожий на файл дампа, который обычно создается при сбое экземпляра JRockit. Он отображает различную информацию о виртуальной машине, такую ​​как аргументы командной строки процесса Java, время работы, тип процессора, состояние кучи, загруженные модули, выпуск libc и т. Д. Проверьте следующую выдержку из примера выполнения:

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
40
41
42
43
44
Uptime       : 5 days, 16:29:55 on Thu Jun 21 12:02:34 2012
Version      : Oracle JRockit(R) R28.1.4-7-144370-1.6.0_26-20110617-2130-linux-ia32
CPU          : Intel Westmere (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64
Number CPUs  : 8
Tot Phys Mem : 12632571904 (12047 MB)
OS version   : Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Linux version 2.6.18-194.26.1.el5PAE (mockbuild@x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Fri Oct 29 14:28:58 EDT 2010 (i686)
Thread System: Linux NPTL
LibC release : 2.5-stable
Java locking : Lazy unlocking enabled (class banning) (transfer banning)
State        : JVM is running (Main thread has finished)
Command Line : -Dprogram.name=run.sh -Xms1536M -Xmx1536M -Djava.net.preferIPv4Stack=true -Xverbose:gc,memory -XverboseLog:/tmp/gc-jrockit.log -Xbootclasspath/p: -XXaggressive -XXcompaction:heapParts=1536 -Xgc:genconcon -Xns:150M -XXgcThreads:2 -XXgcTrigger:50 -XXcompaction:internalPercentage=1.0 -XXcompaction:externalPercentage=1.0 -Xmanagement -Djrockit.managementserver.port=4646 -Dcom.sun.management.jmxremote.ssl=false -Djava.net.preferIPv4Stack=true -Djava.endorsed.dirs=/var/lib/OC/imsc/lib/endorsed -Dsun.java.launcher=SUN_STANDARD com.adrianos.Main
Repository   : /tmp/2012_06_15_19_32_40_21109
java.home    : /usr/java/jrockit-jdk1.6.0_26-R28.1.4-4.0.1.orig/jre
StackOverFlow: 0 StackOverFlowErrors have occured
OutOfMemory  : 0 OutOfMemoryErrors have occured
C Heap       : Good; no memory allocations have failed
GC Strategy  : Mode: pausetime, with strategy: genconcon (basic strategy: genconcon)
GC Status    : OC is not running. Last finished OC was OC#5287.
             : YC is not running. Last finished YC was YC#16925.
YC Promotion : Last YC successfully promoted all objects
YC History   : Ran 3 YCs before OC#5283.
             : Ran 3 YCs before OC#5284.
             : Ran 3 YCs before OC#5285.
             : Ran 3 YCs before OC#5286.
             : Ran 3 YCs before OC#5287.
             : Ran 2 YCs since last OC.
Heap         : 0x5661a000 - 0xb661a000  (Size: 1536 MB)
Compaction   : (no compaction area)
Allocation   : TLA-min: 2048, TLA-preferred: 20480 TLA-waste limit: 2048
NurseryList  : 0x869370d8 - 0x941e0390
KeepArea     : 0x8da6c078 - 0x941e0390
KA Markers   : [ 0x8b4857c80x8da6c078 , 0x941e0390 ]
Forbidden A  : (none)
Previous KA  : 0x8b4857c8 - 0x8da6c078
Previous FA  : (none)
CompRefs     : References are 32-bit.
...
...
Loaded modules:
08048000-08057193  /usr/java/jrockit-jdk1.6.0_26-R28.1.4-4.0.1.orig/bin/java
b7f12000-b7f1262b  /usr/java/jrockit-jdk1.6.0_26-R28.1.4-4.0.1.orig/bin/java
...
...

5) Создайте запись полета $> jrcmd <pid> start_flightrecording name = myrecord1 filename = / var / tmp / myrecord1.jfr длительность = 60с сжатие = истинные настройки = / my / path / xxx.jfs

Запускает запись JRockit Flight Recorder, которая может помочь вам проанализировать поведение вашего кода и найти потенциальные проблемы (например, узкие места). Это действительно полезно, чтобы понять, что делают ваши темы. В каталоге JROCKIT_HOME / jre / lib / jfr находится множество шаблонов.

6) Создайте дамп кучи $> jrcmd <pid> hprofdump filename = / tmp / jrockit1.hprof

Создавайте дампы кучи в популярном формате HPROF , который можно использовать для устранения утечек памяти или для лучшего понимания вашего кода. Вы можете проанализировать этот файл с помощью превосходного Eclipse Memory Analyzer Tool ( MAT ) или анализатора памяти Java по умолчанию VisualVM . Общие советы:

  1. Вы должны быть осторожны с последними 2 командами, поскольку они очень полезны, но требуют дополнительных ресурсов от JVM. Избегайте их выполнения в часы с интенсивным движением, кроме случаев, когда они вам действительно нужны. Имейте в виду, что если JVM находится в очень « сложном » состоянии, он не допустит таких действий.
  2. MAT — отличный инструмент, и я люблю его. НО, если вы хотите быть полностью подготовленным, вы также должны поиграть с VisualVM, как это предусмотрено при установке Hotspot по умолчанию. Это означает, что VisualVM всегда рядом, и вам не нужен дополнительный графический инструмент для проверки чего-то простого. Я был в таком случае, когда у меня не было доступа в Интернет, и использование моего ноутбука было запрещено.

Я надеюсь, что вы найдете эти детали полезными.

Ссылка: JRockit — полезные команды JRCMD от нашего партнера по JCG Адрианоса Дадиса в Java, Integration и достоинства исходного блога.