分析java進程假死狀況

標籤：heap   導致   資訊   exception   bin   資料結構   jdk   tab   命令使用   

摘自：

http://www.myexception.cn/internet/2044496.html

 

分析java進程假死情況

1 引言

 

1.1 編寫目的

 

 為了方便大家以後發現進程假死的時候能夠正常的分析並且第一時間保留現場快照。

 

1.2編寫背景

 

最近伺服器發現tomcat的應用會偶爾出現無法訪問的情況。經過一段時間的觀察最近又發現有台tomcat的應用出現了無法訪問情況。簡單描述下該台tomcat當時具體的表現：用戶端請求沒有響應，查看伺服器端tomcat的進程是存活的，查看業務日誌的時候發現日誌停止沒有任何最新的訪問日誌。連tomcat下面的catalina.log也沒有任何訪問記錄，基本斷定該台tomcat已不能提供服務。

 

2 分析步驟

 

根據前面我描述的假死現象，我最先想到的是網路是否出現了問題，是不是有什麼丟包嚴重的情況，於是我開始從請求的資料流程開始分析，由於我們業務的架構採用的是nginx+tomcat的叢集配置，一個請求上來的流向可以用來簡單的描述一下：

 

 

 

2.1檢查nginx的網路情況

 

更改nginx的配置，讓該台nginx請求只轉到本機器的出現問題的tomcat應用上面，在access.log裡看是否有網路請求，結果可以查看到當前所有的網路請求，也就是說可以排除是網路的問題。

 

2.2檢查tomcat 的網路情況

 

分析業務配置的tomcat訪問日誌xxxx.log上是否有日誌訪問記錄，經過查詢該台tomcat應用日誌完全沒有任何訪問記錄，由於我們的部署是原生nginx轉到原生tomcat應用，所以可以排除不是網路問題。到此基本可以斷定網路沒有問題，tomcat 本身出現了假死的情況。在tomcat的日誌裡有報過OutOfMemoryError的異常，所以可以肯定tomcat假死的原因是OOM

 

3 分析JVM記憶體溢出

 

3.1 為什麼會發生記憶體流失

 

在我們學習Java的時候就知道它最為方便的地方就是我們不需要管理記憶體的分配和釋放，一切由JVM自己來進行處理，當Java對象不再被應用時，等到堆記憶體不夠用時JVM會進行GC處理，清除這些對象佔用的堆記憶體空間，但是如果對象一直被應用，那麼JVM是無法對其進行GC處理的，那麼我們建立新的對象時，JVM就沒有辦法從堆中擷取足夠的記憶體配置給此對象，這時就會導致OOM。我們出現OOM原因，一般都是因為我們不斷的往容器裡存放對象，然而容器沒有相應的大小限制或清除機制，這樣就容易導致OOM。

 

3.2 快速定位問題

 

    當我們的應用伺服器佔用了過多記憶體的時候，我們怎麼樣才能快速的定位問題呢？要想快速定位問題，首先我們必需擷取伺服器JVM某時刻的記憶體快照。Jdk裡面提供了很多相應的命令比如：jstack,jstat,jmap,jps等等. 在出現問題後我們應該快速保留現場。

 

3.2.1 jstack

 

可以觀察到jvm中當前所有線程的運行情況和線程目前狀態.

 

sudo jstack -F 進程ID
輸出內容如下：

 

從上面的圖我們可以看到tomcat進程裡面沒有死結的情況，而且每個線程都處理等待的狀態。這個時候我們可以telnet命令連上tomcat的連接埠查看tomcat進程是否有任務回應。這時發現tomcat沒有任何回應可以證明tomcat應用已沒有響應處理假死狀態。

 

3.2.2 jstat

這是jdk命令中比較重要，也是相當實用的一個命令，可以觀察到classloader，compiler，gc相關資訊
具體參數如下：
-class：統計class loader行為資訊
-compile：統計編譯行為資訊
-gc：統計jdk gc時heap資訊
-gccapacity：統計不同的generations（包括新生區，老年區，permanent區）相應的heap容量情況
-gccause：統計gc的情況，（同-gcutil）和引起gc的事件
-gcnew：統計gc時，新生代的情況
-gcnewcapacity：統計gc時，新生代heap容量
-gcold：統計gc時，老年區的情況
-gcoldcapacity：統計gc時，老年區heap容量
-gcpermcapacity：統計gc時，permanent區heap容量
-gcutil：統計gc時，heap情況
-printcompilation：不知道幹什麼的，一直沒用過。

一般比較常用的幾個參數是：
sudo jstat -class 2083 1000 10 （每隔1秒監控一次，一共做10次）

 

查看當時的head情況

 

sudo jstat -gcutil  20683 2000

 

註：該圖不是出錯截取

 

出現時候截取的資料是gc已經完全沒有處理了,因為沒有加上full gc的日誌所以不確定JVMGC 時間過長，導致應用暫停.

 

3.2.3擷取記憶體快照

 

Jdk內建的jmap可以擷取內在某一時刻的快照

 

命令：jmap -dump:format=b,file=heap.bin <pid>
file：儲存路徑及檔案名稱
pid：進程編號（windows通過工作管理員查看，linux通過ps aux查看）
dump檔案可以通過MemoryAnalyzer分析查看，網址：http://www.eclipse.org/mat/，可以查看dump時對象數量，記憶體佔用，線程情況等。

 

 從上面的圖可以看得出來對象沒有記憶體溢出。

從我們可以明確的看出此項目的HashMap記憶體使用量率比較高，因為我們的系統都是返回Map的資料結構所以佔用比較高的記憶體是正常情況。

 

 

3.2.4觀察運行中的jvm實體記憶體的佔用情況    

 

觀察運行中的jvm實體記憶體的佔用情況。我們也可以用jmap命令
參數如下：
-heap：列印jvm heap的情況
-histo：列印jvm heap的長條圖。其輸出資訊包括類名，對象數量，對象佔用大小。
-histo：live ：同上，但是只答應存活對象的情況
-permstat：列印permanent generation heap情況

命令使用：
jmap -heap 2083
可以觀察到New Generation（Eden Space，From Space，To Space）,tenured generation,Perm Generation的記憶體使用量情況
輸出內容：

 

為tomcat應用出錯前JVM的配置資訊,可以明確的看到當時的資訊:

 

MaxHeapSize堆記憶體大小為：3500M

 

MaxNewSize新生代記憶體大小：512M

 

PermSize永久代記憶體大小:192M

 

NewRatio設定年輕代（包括Eden和兩個Survivor區）與年老代的比值（除去持久代）。設定為2，則年輕代與年老代所佔比值為1：2，年輕代占整個堆棧的1/3

 

SurvivorRatio設定年輕代中Eden區與Survivor區的大小比值。設定為8，則兩個Survivor區與一個Eden區的比值為2:8，一個Survivor區占整個年輕代的1/10

 

 

 

在New Generation中，有一個叫Eden的空間，主要是用來存放新生的對象，還有兩個Survivor Spaces（from,to）, 它們用來存放每次記憶體回收後存活下來的對象。在Old Generation中，主要存放應用程式中生命週期長的記憶體對象，還有個Permanent Generation，主要用來放JVM自己的反射對象，比如類對象和方法對象等。

 

 

 

 

從上面的圖可以看出來JVM的新生代設定太小，可以看出應用的新生代區完全佔滿了，無法再往新生代區增加新的對象此時的這些對象都處於活躍狀態，所以不會被GC處理，但是tomcat應用還在繼續產生新的對象，這樣就會導致OOM的發生，這就是導致tomcat假死的原因.

 

4 Tomcat假死其它情況

 

         以下是網上資料說的tomcat假的情況：

 

1、應用本身程式的問題，造成死結。

 

2、load 太高，已經超出服務的極限

 

3、jvm GC 時間過長，導致應用暫停

 

         因為出錯項目裡面沒有打出GC的處理情況，所以不確定此原因是否也是我項目tomcat假死的原因之一。

 

4、大量tcp 串連 CLOSE_WAIT

 

netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}‘ 

 

TIME_WAIT 48

 

CLOSE_WAIT 2228

 

ESTABLISHED 86

 

常用的三個狀態是：ESTABLISHED 表示正在通訊，TIME_WAIT 表示主動關閉，CLOSE_WAIT 表示被動關

分析java進程假死狀況