Java自帶的效能監測工具用法簡介
https://blog.csdn.net/xad707348125/article/details/51985854
https://www.cnblogs.com/yjd_hycf_space/p/7755633.html
http://www.cnblogs.com/alipayhutu/archive/2012/08/20/2647353.html
問題: 發現jstat,jmap等命令不存在的
解決:
yum install java-1.8.0-openjdk-devel-debug
問題: Unable to open socket file: target process not responding or HotSpot VM not loaded
Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
解決:
在用jstack工具檢視jvm執行緒的執行情況時出現上述錯誤。就是因為該程序長時間沒有啟停,在/tmp/hsperfdata_'username'/資料夾下的該程序檔案被Linux自身的機制(tmp下面不能存放很多檔案)刪除,需重新啟停。所以要注意/etc/cron.daily/tmpwatch改檔案在生產的情況。否則出現記憶體洩漏,或者記憶體溢位時,很難排查,或者出現系統執行緩慢時,想要觀察系統執行情況也沒辦法,再或者,想把現場儲存至dump檔案中,等待大神解決也不能做。
對線上伺服器的java應用dump操作時發現,以下報錯,不能dump。jps也獲取不到java程序的pid。
# jmap -dump:file=/data/dump/jvm_en.hprof 20176
20176: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
重啟後,jps可以獲得該java程序的pid,jstack也可以dump執行緒。
jps
- 檢視所有的jvm程序,包括程序ID,程序啟動的路徑等等。
- 我自己也用PS,即:ps -ef | grep java
jstack
- 觀察jvm中當前所有執行緒的執行情況和執行緒當前狀態。
- 系統崩潰了?如果java程式崩潰生成core檔案,jstack工具可以用來獲得core檔案的java stack和native stack的資訊,從而可以輕鬆地知道java程式是如何崩潰和在程式何處發生問題。
- 系統hung住了?jstack工具還可以附屬到正在執行的java程式中,看到當時執行的java程式的java stack和native stack的資訊, 如果現在執行的java程式呈現hung的狀態,jstack是非常有用的。
jstat
- jstat利用JVM內建的指令對Java應用程式的資源和效能進行實時的命令列的監控,包括了對程序的classloader,compiler,gc情況;
- 特別的,一個極強的監視記憶體的工具,可以用來監視VM記憶體內的各種堆和非堆的大小及其記憶體使用量,以及載入類的數量。
jmap
- 監視程序執行中的jvm物理記憶體的佔用情況,該程序記憶體內,所有物件的情況,例如產生了哪些物件,物件數量;
- 系統崩潰了?jmap 可以從core檔案或程序中獲得記憶體的具體匹配情況,包括Heap size, Perm size等等
jinfo
- 觀察程序執行環境引數,包括Java System屬性和JVM命令列引數
- 系統崩潰了?jinfo可以從core檔案裡面知道崩潰的Java應用程式的配置資訊。
jstat命令檢視jvm的GC情況 (以Linux為例)
jstat命令可以檢視堆記憶體各部分的使用量,以及載入類的數量。命令的格式如下:
jstat [-命令選項] [vmid] [間隔時間/毫秒] [查詢次數]
注意!!!:使用的jdk版本是jdk8.
類載入統計:
- Loaded:載入class的數量
- Bytes:所佔用空間大小
- Unloaded:未載入數量
- Bytes:未載入佔用空間
- Time:時間
編譯統計
- Compiled:編譯數量。
- Failed:失敗數量
- Invalid:不可用數量
- Time:時間
- FailedType:失敗型別
- FailedMethod:失敗的方法
垃圾回收統計
- S0C:第一個倖存區的大小
- S1C:第二個倖存區的大小
- S0U:第一個倖存區的使用大小
- S1U:第二個倖存區的使用大小
- EC:伊甸園區的大小
- EU:伊甸園區的使用大小
- OC:老年代大小
- OU:老年代使用大小
- MC:方法區大小
- MU:方法區使用大小
- CCSC:壓縮類空間大小
- CCSU:壓縮類空間使用大小
- YGC:年輕代垃圾回收次數
- YGCT:年輕代垃圾回收消耗時間
- FGC:老年代垃圾回收次數
- FGCT:老年代垃圾回收消耗時間
- GCT:垃圾回收消耗總時間
堆記憶體統計
- NGCMN:新生代最小容量
- NGCMX:新生代最大容量
- NGC:當前新生代容量
- S0C:第一個倖存區大小
- S1C:第二個倖存區的大小
- EC:伊甸園區的大小
- OGCMN:老年代最小容量
- OGCMX:老年代最大容量
- OGC:當前老年代大小
- OC:當前老年代大小
- MCMN:最小元資料容量
- MCMX:最大元資料容量
- MC:當前元資料空間大小
- CCSMN:最小壓縮類空間大小
- CCSMX:最大壓縮類空間大小
- CCSC:當前壓縮類空間大小
- YGC:年輕代gc次數
- FGC:老年代GC次數
新生代垃圾回收統計
- S0C:第一個倖存區大小
- S1C:第二個倖存區的大小
- S0U:第一個倖存區的使用大小
- S1U:第二個倖存區的使用大小
- TT:物件在新生代存活的次數
- MTT:物件在新生代存活的最大次數
- DSS:期望的倖存區大小
- EC:伊甸園區的大小
- EU:伊甸園區的使用大小
- YGC:年輕代垃圾回收次數
- YGCT:年輕代垃圾回收消耗時間
新生代記憶體統計
- NGCMN:新生代最小容量
- NGCMX:新生代最大容量
- NGC:當前新生代容量
- S0CMX:最大幸存1區大小
- S0C:當前倖存1區大小
- S1CMX:最大幸存2區大小
- S1C:當前倖存2區大小
- ECMX:最大伊甸園區大小
- EC:當前伊甸園區大小
- YGC:年輕代垃圾回收次數
- FGC:老年代回收次數
老年代垃圾回收統計
- MC:方法區大小
- MU:方法區使用大小
- CCSC:壓縮類空間大小
- CCSU:壓縮類空間使用大小
- OC:老年代大小
- OU:老年代使用大小
- YGC:年輕代垃圾回收次數
- FGC:老年代垃圾回收次數
- FGCT:老年代垃圾回收消耗時間
- GCT:垃圾回收消耗總時間
老年代記憶體統計
- OGCMN:老年代最小容量
- OGCMX:老年代最大容量
- OGC:當前老年代大小
- OC:老年代大小
- YGC:年輕代垃圾回收次數
- FGC:老年代垃圾回收次數
- FGCT:老年代垃圾回收消耗時間
- GCT:垃圾回收消耗總時間
元資料空間統計
- MCMN: 最小元資料容量
- MCMX:最大元資料容量
- MC:當前元資料空間大小
- CCSMN:最小壓縮類空間大小
- CCSMX:最大壓縮類空間大小
- CCSC:當前壓縮類空間大小
- YGC:年輕代垃圾回收次數
- FGC:老年代垃圾回收次數
- FGCT:老年代垃圾回收消耗時間
- GCT:垃圾回收消耗總時間
總結垃圾回收統計
- S0:倖存1區當前使用比例
- S1:倖存2區當前使用比例
- E:伊甸園區使用比例
- O:老年代使用比例
- M:元資料區使用比例
- CCS:壓縮使用比例
- YGC:年輕代垃圾回收次數
- FGC:老年代垃圾回收次數
- FGCT:老年代垃圾回收消耗時間
- GCT:垃圾回收消耗總時間
JVM編譯方法統計
- Compiled:最近編譯方法的數量
- Size:最近編譯方法的位元組碼數量
- Type:最近編譯方法的編譯型別。
- Method:方法名標識。