一、摘要
由於硬件問題、系統資源緊缺或者程序本身的BUG,Java服務在線上不可避免地會出現一些“系統性”故障,比如:服務性能明顯下降、部分(或所有)接口超時或卡死等。其中部分故障隱藏頗深,對運維和開發造成長期困擾。筆者根據自己的學習和實踐,總結出一套行之有效的“逐步排除”的方法,來快速定位Java服務線上“系統性”故障。
二、導言
Java語言是廣泛使用的語言,它具有跨平臺的特性和易學易用的特點,很多服務端應用都採用Java語言開發。由於軟件系統本身以及運行環境的複雜性,Java的應用不可避免地會出現一些故障。儘管故障的表象通常比較明顯(服務反應明顯變慢、輸出發生錯誤、發生崩潰等),但故障定位卻並不一定容易。爲什麼呢?有如下原因:
1. 程序打印的日誌越詳細,越容易定位到BUG,但是可能有些時候程序中沒有打印相關內容到日誌,或者日誌級別沒有設置到相應級別
2. 程序可能只對很特殊的輸入條件發生故障,但輸入條件難以推斷和復現
3. 通常自己編寫的程序出現的問題會比較容易定位,但應用經常是由多人協作編寫,故障定位人員可能並不熟悉其他人員編寫的程序
4. 應用通常會依賴很多第三方庫,第三方庫中隱藏着的BUG可能是始料未及的
5. 多數的開發人員學習的都是“如何編寫業務功能”的技術資料,但對於“如何編寫高效、可靠的程序”、“如何定位程序故障”卻知之甚少。所以一旦應用出現故障,他們並沒有足夠的技術背景知識來幫助他們完成故障定位。
儘管有些故障會很難定位,但筆者根據學習和實踐總結出一套“逐步排除”的故障定位方法:通過操作系統和Java虛擬機提供的監控和診斷工具,獲取到系統資源和目標服務(出現故障的Java服務)內部的狀態,並依據服務程序的特點,識別出哪些現象是正常的,哪些現象是異常的。而後通過排除正常的現象,和跟蹤異常現象,就可以達到故障定位的目標。
在正式介紹該方法之前,先申明一下這個方法使用的範圍。
三、本方法適用的範圍
本方法主要適用於Linux系統中Java服務線上“系統性”故障的定位,比如:服務性能明顯下降、部分(或所有)接口超時或卡死。其它操作系統或其它語言的服務,也可以參考本文的思路。
不適用本方法的情況:對於“功能性”故障,例如運算結果不對、邏輯分支走錯等,不建議使用本方法。對待這些情況比較恰當的方法是在測試環境中重現,並使用Java虛擬機提供的“遠程調試”功能進行動態跟蹤調試。
前面說過,本方法基於“異常現象”的識別來定位故障。那系統中可能有哪些異常現象呢?
四、有哪些異常現象
我們可以將異常現象分成兩類:系統資源的異常現象、“目標服務”內部的異常現象。目標服務,指的是出現故障的Java服務。
1. 系統資源的異常現象
一個程序由於BUG或者配置不當,可能會佔用過多的系統資源,導致系統資源匱乏。這時,系統中其它程序就會出現計算緩慢、超時、操作失敗等“系統性”故障。常見的系統資源異常現象有:CPU佔用過高、物理內存富餘量極少、磁盤I/O佔用過高、發生換入換出過多、網絡鏈接數過多。可以通過top、iostat、vmstat、netstat工具獲取到相應情況。
2. 目標服務內部的異常現象
Java堆滿
Java堆是“Java虛擬機”從操作系統申請到的一大塊內存,用於存放Java程序運行中創建的對象。當Java堆滿或者較滿的情況下,會觸發“Java虛擬機”的“垃圾收集”操作,將所有“不可達對象”(即程序邏輯不能引用到的對象)清理掉。有時,由於程序邏輯或者Java堆參數設置的問題,會導致“可達對象”(即程序邏輯可以引用到的對象)佔滿了Java堆。這時,Java虛擬機就會無休止地做“垃圾回收”操作,使得整個Java程序會進入卡死狀態。我們可以使用jstat工具查看Java堆的佔用率。
日誌中的異常
目標服務可能會在日誌中記錄一些異常信息,例如超時、操作失敗等信息,其中可能含有系統故障的關鍵信息。
疑難雜症死鎖、死循環、數據結構異常(過大或者被破壞)、集中等待外部服務迴應等現象。這些異常現象通常採用jstack工具可以獲取到非常有用的線索。
瞭解異常現象分類之後,我們來具體講講故障定位的步驟。
五、故障定位的步驟
我們採用“從外到內,逐步排除”的方式來定位故障:
1. 先排除其它程序過度佔用系統資源的問題
2. 然後排除“目標服務”本身佔用系統資源過度的問題
3. 最後觀察目標服務內部的情況,排除掉各種常見故障類型。
對於不能排除的方面,要根據該信息對應的“危險程度”來判斷是應該“進一步深入”還是“暫時跳過”。
例如“目標服務Java堆佔用100%”這是一條危險程度較高的信息,建議立即“進一步深入”。而對於“在CPU核數爲8的機器上,其它程序偶然佔用CPU達200%”這種危險程度不是很高的信息,則建議“暫時跳過”。當然,有些具體情況還需要故障排查人員根據自己的經驗做出判斷。
第一步:排除其它程序佔用過量系統資源的情況
圖示:排除其它程序佔用過量系統資源的情況
1. 運行【top】,檢查CPU idle情況,如果發現idle較多(例如多餘50%),則排除其它進程佔用CPU過量的情況。
如果idle較少,則按shift+p,將進程按照CPU佔用率從高到低排序,逐一排查(見下面TIP)。
2. 運行【free -g】,檢查剩餘物理內存(“-/+ buffer/cache”行的“free”列)情況,如果發現剩餘物理內存較多(例如剩餘2GB以上),則排除佔用物理內存過量的情況。
如果剩餘物理內存較少(例如剩餘1GB以下),則運行【vmstat -n 1】檢查si/so(換入換出)情況,
第一行數值表示的是從系統啓動到運行命令時的均值,我們忽略掉。從第二行開始,每一行的si/so表示該秒內si/so的block數。如果多行數值都爲零,則可以排除物理內存不足的問題。如果數值較大(例如大於1000 blocks/sec,block的大小一般是1KB)則說明存在較明顯的內存不足問題。我們可以運行【top】輸入shift+m,將進程按照物理內存佔用(“RES”列)從大到小進行排序,然後對排前面的進程逐一排查(見下面TIP)。
3. 如果目標服務是磁盤I/O較重的程序,則用【iostat -d 1】,檢查磁盤I/O情況。若“目標服務對應的磁盤”讀寫量在預估之內(預估要注意cache機制的影響),則排除其它進程佔用磁盤I/O過量的問題。
第一組數據是從該機器從開機以來的統計值。從第二組開始,都是每秒鐘的統計值。通過【df】命令,可以看到Device與目錄的關係。下圖設備“sdb”就對應了目錄“/disk2”。
假如發現目標服務所在磁盤讀寫量明顯超過推算值,則應該找到大量讀寫磁盤的進程(見下面TIP)
4. 運行【netstat -aonp | grep tcp| wc -l】查看各種狀態的TCP連接數量和。如果總數較小(例如小於500),則排除連接數佔用過多問題。
假如發現連接數較多,可以用【netstat -natp|awk ‘{print $7}’|sort|uniq -c|sort -rn】按照PID統計TCP連接的數量,然後對連接數較多的進程逐一排查(見下面TIP)。
TIP:如何“逐一排查”:
假如定位到是某個外部程序佔用過量系統資源,則依據進程的功能和配置情況判斷是否合乎預期。假如符合預期,則考慮將服務遷移到其他機器、修改程序運行的磁盤、修改程序配置等方式解決。假如不符合預期,則可能是運行者對該程序不太瞭解或者是該程序發生了BUG。外部程序通常可能是Java程序也可能不是Java程序,如果是Java程序,可以把它當作目標服務一樣進行排查;而非Java程序具體排查方法超出了本文範圍,列出三個工具供參考選用:
系統提供的調用棧的轉儲工具【pstack】,可以瞭解到程序中各個線程當前正在幹什麼,從而瞭解到什麼邏輯佔用了CPU、什麼邏輯佔用了磁盤等
系統提供的調用跟蹤工具【strace】,可以偵測到程序中每個系統API調用的參數、返回值、調用時間等。從而確認程序與系統API交互是否正常等。
系統提供的調試器【gdb】,可以設置條件斷點偵測某個系統函數調用的時候調用棧是什麼樣的。從而瞭解到什麼邏輯不斷在分配內存、什麼邏輯不斷在創建新連接等
TIP:如何“找到大量讀寫磁盤的進程”:
1. 如果Linux系統比較新(kernel v2.6.20以上)可以使用iotop工具獲知每個進程的io情況,較快地定位到讀寫磁盤較多的進程。
2. 通過【ls -l /proc/*/fd | grep 該設備映射裝載到的文件系統路徑】查看到哪個進程打開了該設備的文件,並根據進程身份、打開的文件名、文件大小等屬性判斷是否做了大量讀寫。
3. 可以使用pstack取得進程的線程調用棧,或者strace跟蹤磁盤讀寫API來幫助確認某個進程是否在做磁盤做大量讀寫
第二步:排除目標服務佔用了過量系統資源的情況
圖示:排除目標服務佔用了過量系統資源的情況
1. 運行【top】,shift+p按照“CPU使用”從高到低的排序查看進程,假如目標服務佔用的CPU較低(<100%,即小於一個核的計算量),或者符合經驗預期,則排除目標服務CPU佔用過高的問題。
假如目標服務佔用的CPU較高(>100%,即大於一個核的計算量),則shift+h觀察線程級別的CPU使用分佈。
如果CPU使用分散到多個線程,而且每個線程佔用都不算高(例如都<30%),則排除CPU佔用過高的問題
如果CPU使用集中到一個或幾個線程,而且很高(例如都>95%),則用【jstack pid > jstack.log】獲取目標服務中線程調用棧的情況。top中看到的佔用CPU較高的線程的PID轉換成16進制(字母用小寫),然後在jstack.log中找到對應線程,檢查其邏輯:
假如對應線程是純計算型任務(例如GC、正則匹配、數值計算等),則排除CPU佔用過高的問題。當然如果這種線程佔用CPU總量如果過多(例如佔滿了所有核),則需要對線程數量做控制(限制線程數 < CPU核數)。
假如對應線程不是純計算型任務(例如只是向其他服務請求一些數據,然後簡單組合一下返回給用戶等),而該線程CPU佔用過高(>95%),則可能發生了異常。例如:死循環、數據結構過大等問題,確定具體原因的方法見下文“第三步:目標進程內部觀察”。
2. 運行【top】,shift+m按照“物理內存使用(RES)”從高到低排序進程,評估目標服務佔的內存量是否在預期之內。如果在預期之內,則排除目標服務Native內存佔用過高的問題。
提示:由於Java進程中有Java級別的內存佔用,也有Native級別的內存佔用,所以Java進程的“物理內存使用(RES)”比“-Xmx參數指定的Java堆大小”大一些是正常的(例如1.5~2倍左右)。
假如“物理內存使用(RES)”超出預期較多(例如2倍以上),並且確定JNI邏輯不應該佔用這麼多內存,則可能是NIO或JNI代碼出現了BUG。由於本文主要討論的是Java級別的問題,所以對這種情況不做過多討論。讀者可以參考上文“TIP:如何逐一排查”進行native級別的調試。
第三步:目標服務內部觀察
1. Java堆佔用情況
用【jstat -gcutil pid】查看目標服務的OLD區佔用比例,假如佔用比例低於85%則排除Java堆佔用比例過高的問題。
假如佔用比例較高(例如超過98%),則服務存在Java堆佔滿的問題。這時候可以用jmap+mat進行分析定位內存中佔用比例的情況(見下文TIP),從而較快地定位到Java堆滿的原因。
TIP:用jmap+mat進行分析定位內存中佔用比例的情況
先通過【jmap -dump:file=dump.map pid】取得目標服務的Java堆轉儲,然後找一臺空閒內存較大的機器在VNC中運行mat工具。mat工具中打開dump.map後,可以方便地分析內存中什麼對象引用了大量的對象(從邏輯意義上來說,就是該對象佔用了多大比例的內存)。具體使用可以ca
2. 異常日誌觀察
通過類似【tail -10000 stdout.log.2014-08-15 | grep -B2 -A10 -i exception】這樣的方式,可以查到日誌中最近記錄的異常。
3. 疑難雜症
用【jstack pid > jstack.log】獲取目標服務中“鎖情況”和“各線程調用棧”信息,並分析
檢查jstack.log中是否有deadlock報出,如果沒有則排除deadlock情況。
Found one Java-level deadlock:
=============================
“Thread-0″:
waiting to lock monitor 0x1884337c (object 0x046ac698, a java.lang.Object),
which is held by “main”
“main”:
waiting to lock monitor 0x188426e4 (object 0x046ac6a0, a java.lang.Object),
which is held by “Thread-0″
Java stack information for the threads listed above:
===================================================
“Thread-0″:
at LockProblem$T2.run(LockProblem.java:14)
- waiting to lock <0x046ac698> (a java.lang.Object)
- locked <0x046ac6a0> (a java.lang.Object)
“main”:
at LockProblem.main(LockProblem.java:25)
- waiting to lock <0x046ac6a0> (a java.lang.Object)
- locked <0x046ac698> (a java.lang.Object)
Found 1 deadlock.
如果發現deadlock則則根據jstack.log中的提示定位到對應代碼邏輯。
用【POST http://www.xinitek.com/ajax/summaryJStack < jstack.log > jstack.log.summary】對jstack.log做合併處理,然後繼續分析故障所在。
通過jstack.log.summary中的情況,我們可以較迅速地定位到一些嫌疑點,並可以猜測其故障引起的原因(後文有jstack.log.summary情況舉例供參考)
情況 | 嫌疑點 | 猜測原因 |
線程數量過多 | 某種線程數量過多 | 運行環境中“限制線程數量”的機制失效 |
多個線程在等待一把鎖,但拿到鎖的線程在做某個操作 |
拿到這把鎖的線程在做網絡connect操作 |
被connect的服務異常 |
拿到鎖的線程在做數據結構遍歷操作 |
該數據結構過大或被破壞 |
|
某個耗時的操作被反覆調用 |
某個應當被緩存的對象多次被創建 |
對象池的配置錯誤 |
等待外部服務的響應 |
很多線程都在等待外部服務的響應 |
該外部服務故障 |
很多線程都在等待FutureTask完成,而FutureTask在等待外部服務的響應 |
該外部服務故障 |
猜測了原因後,可以通過日誌檢查、監控檢查、用測試程序嘗試復現等方式確認猜測是否正確。如果需要更細緻的證據來確認,可以通過BTrace、strace、jmap+MAT等工具進行分析,最終確認問題所在。
下面簡單介紹下這幾個工具:
BTrace:用於監測Java級別的方法調用情況。可以對運行中的Java虛擬機插入調試代碼,從而確認方法每次調用的參數、返回值、花費時間等。第三方免費工具。
strace:用於監視系統調用情況。可以得到每次系統調用的參數、返回值、耗費時間等。Linux自帶工具。
jmap+MAT:用於查看Java級別內存情況。jmap是JDK自帶工具,可以將Java程序的Java堆轉儲到數據文件中;MAT是eclipse.org上提供的一個工具,可以檢查jmap轉儲數據文件中的數據。結合這兩個工具,我們可以非常容易地看到Java程序內存中所有對象及其屬性。
TIP:jstack.log.summary情況舉例
1. 某種線程數量過多
1000 threads at
“Timer-0″ prio=6 tid=0x189e3800 nid=0x34e0 in Object.wait() [0x18c2f000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.util.TimerThread.mainLoop(Timer.java:552)
- locked [***] (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
2. 多個線程在等待一把鎖,但拿到鎖的線程在做數據結構遍歷操作
38 threads at
“Thread-44″ prio=6 tid=0×18981800 nid=0x3a08 waiting for monitor entry [0x1a85f000]
java.lang.Thread.State: BLOCKED (on object monitor)
at SlowAction$Users.run(SlowAction.java:15)
- waiting to lock [***] (a java.lang.Object)
1 threads at
“Thread-3″ prio=6 tid=0x1894f400 nid=0×3954 runnable [0x18d1f000]
java.lang.Thread.State: RUNNABLE
at java.util.LinkedList.indexOf(LinkedList.java:603)
at java.util.LinkedList.contains(LinkedList.java:315)
at SlowAction$Users.run(SlowAction.java:18)
- locked [***] (a java.lang.Object)
3. 某個應當被緩存的對象多次被創建(數據庫連接)
99 threads at
“resin-tcp-connection-*:3231-321″ daemon prio=10 tid=0x000000004dc43800 nid=0x65f5 waiting for monitor entry [0x00000000507ff000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- waiting to lock <0x00000000b26ee8a8> (a org.apache.commons.dbcp.PoolableConnectionFactory)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
…
1 threads at
“resin-tcp-connection-*:3231-149″ daemon prio=10 tid=0x000000004d67e800 nid=0x66d7 runnable [0x000000005180f000]
java.lang.Thread.State: RUNNABLE
…
at org.apache.commons.dbcp.DriverManagerConnectionFactory.createConnection(DriverManagerConnectionFactory.java:46)
at org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(PoolableConnectionFactory.java:290)
- locked <0x00000000b26ee8a8> (a org.apache.commons.dbcp.PoolableConnectionFactory)
at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:771)
at org.apache.commons.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
at …
4. 很多線程都在等待外部服務的響應
100 threads at
prio=6 tid=0x189cdc00 nid=0×2904 runnable [0x18d5f000]
RUNNABLE :
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
…
at RequestingService$RPCThread.run(RequestingService.java:24)
5. 很多線程都在等待FutureTask完成,而FutureTask在等待外部服務的響應
100 threads at
6 tid=0×18861000 nid=0x38b0 waiting on condition [0x1951f000] =
WAITING (parking) :
at sun.misc.Unsafe.park(Native Method)
- parking to wait for [***] (a java.util.concurrent.FutureTask$Sync)
186) :
834) :
994) :
1303) :
248) :
111) :
51) :
100 threads at
prio=6 tid=0x188fc000 nid=0×2834 runnable [0x1d71f000]
RUNNABLE :
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
…
at IndirectWait.request(IndirectWait.java:23)
at IndirectWait$MyThread$1.call(IndirectWait.java:46)
at IndirectWait$MyThread$1.call(IndirectWait.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
722) :
爲方便讀者使用,將故障定位三個步驟的圖合併如下:
圖示:故障定位步驟彙總
故障定位是一個較複雜和需要經驗的過程,如果現在故障正在發生,對於分析經驗不很多的開發或運維人員,有什麼簡單的操作步驟記錄下需要的信息嗎?下面提供一個
六、給運維人員的簡單步驟
如果事發突然且不能留着現場太久,要求運維人員:
1. top: 記錄cpu idle%。如果發現cpu佔用過高,則c, shift+h, shift + p查看線程佔用CPU情況,並記錄
2. free: 查看內存情況,如果剩餘量較小,則top中shift+m查看內存佔用情況,並記錄
3. 如果top中發現佔用資源較多的進程名稱(例如java這樣的通用名稱)不太能說明進程身份,則要用ps xuf | grep java等方式記錄下具體進程的身份
4. 取jstack結果。假如取不到,嘗試加/F
jstack命令:jstack PID > jstack.log
5. jstat查看OLD區佔用率。如果佔用率到達或接近100%,則jmap取結果。假如取不到,嘗試加/F
jstat命令: jstat -gcutil PID
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 21.35 88.01 97.35 59.89 111461 1904.894 1458 291.369 2196.263
jmap命令: jmap -dump:file=dump.map PID
6. 重啓服務
參考資料
BTrace官網
MAT官網
使用jmap和MAT觀察Java程序內存數據
使用Eclipse遠程調試Java應用程序
Linux下輸入【man strace/top/iostat/vmstat/netstat/jstack】
都看到這裏了,點贊留言分享一下嘛!!
- END -
本文分享自微信公衆號 - JAVA開發大本營(gh_42999193133a)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。