jrockit

自2007年以來，我一直在使用JRockit。我發現它的速度比Hotspot慢，但在診斷和分析問題上總是更好。 從去年夏天開始，我一直在為一家國際電信系統供應商工作。 我們在HP OpenCall融合通信平臺之上為電信運營商設計和實施各種產品。 我是開源和自由軟件的迷，但是該平臺僅在JRockit VM上運行 。 我們已經對其進行了調整，以實現低延遲并且運行非常酷，但是我們遇到了各種各樣的問題，在JRockit的幫助下，我們為故障排除提供了很多幫助。

我將在此處描述JRCMD的一些有用命令。 JRCMD是一個小型命令行工具，可用于與正在運行的JRockit實例進行交互。

摘要：

獲取線程轉儲

內存利用率

基于類的堆內存分析

虛擬機狀態

創建飛行記錄

產生堆轉儲

細節：

1）獲取線程轉儲 $> jrcmd <pid> print_threads [nativestack = true]

這是通常的SIGQUIT處理程序，可打印所有線程堆棧。 您也可以使用經典方式獲得線程：“ $> kill -3 <pid> ”

無論如何，您都會得到如下的線程轉儲：

===== FULL THREAD DUMP ===============Thu Jun 21 11:38:19 2012Oracle 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, daemonat 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, daemonat 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進程分配的內存（包括本機代碼）。 列：a）內存空間的名稱，b）為該空間映射多少內存，c）額外的詳細信息。 示例運行如下：

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）第一次調用時的大小變化此命令，e）類的全名。 檢查下一個示例運行，其中“ org / adrianos / MyDTO”類的對象可能存在問題：

--------- Detailed Heap Statistics: --------- 61.1% 939735k 6772960 +939735k [C 16.4% 252243k 10762404 +252243k java/lang/String7.0% 107516k 3947228 +107516k [Ljava/lang/String;4.5% 69265k 369180 +69265k [Ljava/lang/Object;1.6% 24127k 205889 +24127k org/adrianos/MyDTO1.3% 19486k 1247140 +19486k java/lang/Long1.0% 15551k 26621 +15551k [B0.6% 8871k 9700 +8871k [I0.6% 8710k 103896 +8710k [Ljava/util/HashMap$Entry;1537175kB total ------------ End of Detailed Heap Statistics ---

4）VM $> jrcmd <pid> print_vm_state的狀態

此命令產生的輸出類似于在JRockit實例崩潰時通常創建的轉儲文件。 它顯示了VM的各種信息，例如java進程的命令行參數，正常運行時間，CPU類型，堆狀態，加載的模塊，libc版本等。請檢查示例運行的下一個摘錄：

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 : [ 0x8b4857c8, 0x8da6c078 , 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名稱= myrecord1文件名= / var / tmp / myrecord1.jfr持續時間= 60s compress = true設置= / my / path / xxx.jfs

啟動JRockit飛行記錄器記錄，該記錄可以幫助您分析代碼的行為并發現潛在的問題（例如瓶頸）。 這對于了解線程在做什么非常有用。 JROCKIT_HOME / jre / lib / jfr目錄中有很多模板。

6）產生堆轉儲 $> jrcmd <pid> hprofdump filename = / tmp / jrockit1.hprof

以流行的HPROF格式生成堆轉儲，可用于解決內存泄漏或對代碼有更好的了解。 您可以使用出色的Eclipse內存分析器工具（ MAT ）或默認的Java內存分析器VisualVM來分析此文件。 一般提示：

您必須小心最后兩個命令，因為它們非常有用，但需要JVM提供額外的資源。 避免在交通繁忙時執行它們，除非您確實需要它們。 請記住，如果JVM處于非常“ 困難 ”的狀態，則將不允許此類操作。

MAT是一個很棒的工具，我喜歡它。 但是，如果要做好充分的準備，則還必須使用Hotspot的默認安裝中存在的VisualVM。 這意味著VisualVM始終存在，并且您不需要額外的圖形工具即可檢查簡單的內容。 我遇到過這樣的情況，我無法訪問互聯網，并且禁止使用筆記本電腦。

希望您會發現這些詳細信息有用。

參考： JRockit –來自我們的JCG合作伙伴 Adrianos Dadis的Java，Integration和源博客優點的 JRCMD有用命令 。

翻譯自: https://www.javacodegeeks.com/2012/06/jrockit-jrcmd-useful-commands.html

jrockit

總結

以上是生活随笔為你收集整理的jrockit_JRockit – JRCMD有用的命令的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。