線上應用故障排查之一：高CPU佔用
一個應用佔用CPU很高，除了確實是計算密集型應用之外，通常原因都是出現了死迴圈。（友情提示：本博文章歡迎轉載，但請註明出處：hankchen，http://www.blogjava.net/hankchen）
以我們最近出現的一個實際故障為例，介紹怎麼定位和解決這類問題。
根據top命令，發現PID為28555的Java程序佔用CPU高達200%，出現故障。
通過ps aux | grep PID命令，可以進一步確定是tomcat程序出現了問題。但是，怎麼定位到具體執行緒或者程式碼呢？
首先顯示執行緒列表:
ps -mp pid -o THREAD,tid,time
找到了耗時最高的執行緒28802，佔用CPU時間快兩個小時了！
其次將需要的執行緒ID轉換為16進位制格式：
printf "%x\n" tid
最後列印執行緒的堆疊資訊：
jstack pid |grep tid -A 30
找到出現問題的程式碼了！
現在來分析下具體的程式碼：ShortSocketIO.readBytes(ShortSocketIO.java:106)
ShortSocketIO是應用封裝的一個用短連線Socket通訊的工具類。readBytes函式的程式碼如下：
public byte[] readBytes(int length) throws IOException { if ((this.socket == null) || (!this.socket.isConnected())) { throw new IOException("++++ attempting to read from closed socket"); } byte[] result = null; ByteArrayOutputStream bos = new ByteArrayOutputStream(); if (this.recIndex >= length) { bos.write(this.recBuf, 0, length); byte[] newBuf = new byte[this.recBufSize]; if (this.recIndex > length) { System.arraycopy(this.recBuf, length, newBuf, 0, this.recIndex - length); } this.recBuf = newBuf; this.recIndex -= length; } else { int totalread = length; if (this.recIndex > 0) { totalread -= this.recIndex; bos.write(this.recBuf, 0, this.recIndex); this.recBuf = new byte[this.recBufSize]; this.recIndex = 0; } int readCount = 0; while (totalread > 0) { if ((readCount = this.in.read(this.recBuf)) > 0) { if (totalread > readCount) { bos.write(this.recBuf, 0, readCount); this.recBuf = new byte[this.recBufSize]; this.recIndex = 0; } else { bos.write(this.recBuf, 0, totalread); byte[] newBuf = new byte[this.recBufSize]; System.arraycopy(this.recBuf, totalread, newBuf, 0, readCount - totalread); this.recBuf = newBuf; this.recIndex = (readCount - totalread); } totalread -= readCount; } } }
問題就出在標紅的程式碼部分。如果this.in.read()返回的資料小於等於0時，迴圈就一直進行下去了。而這種情況在網路擁塞的時候是可能發生的。
至於具體怎麼修改就看業務邏輯應該怎麼對待這種特殊情況了。
最後，總結下排查CPU故障的方法和技巧有哪些：
1、top命令：Linux命令。可以檢視實時的CPU使用情況。也可以檢視最近一段時間的CPU使用情況。
2、PS命令：Linux命令。強大的程序狀態監控命令。可以檢視程序以及程序中執行緒的當前CPU使用情況。屬於當前狀態的取樣資料。
3、jstack：Java提供的命令。可以檢視某個程序的當前執行緒棧執行情況。根據這個命令的輸出可以定位某個程序的所有執行緒的當前執行狀態、執行程式碼，以及是否死鎖等等。
4、pstack：Linux命令。可以檢視某個程序的當前執行緒棧執行情況。
解決方案
1. 排查應用是否建立了過多的執行緒
通過jstack確定應用建立了多少執行緒？超量建立的執行緒的堆疊資訊是怎樣的？誰建立了這些執行緒？一旦明確了這些問題，便很容易解決。
2. 調整作業系統執行緒數閾值 作業系統會限制程序允許建立的執行緒數，使用ulimit -u命令檢視限制。某些伺服器上此閾值設定的過小，比如1024。一旦應用建立超過1024個執行緒，就會遇到java.lang.OutOfMemoryError: unable to create new native thread問題。如果是這種情況，可以調大作業系統執行緒數閾值。
3. 增加機器記憶體 如果上述兩項未能排除問題，可能是正常增長的業務確實需要更多記憶體來建立更多執行緒。如果是這種情況，增加機器記憶體。
4. 減小堆記憶體 一個老司機也經常忽略的非常重要的知識點：執行緒不在堆記憶體上建立，執行緒在堆記憶體之外的記憶體上建立。所以如果分配了堆記憶體之後只剩下很少的可用記憶體，依然可能遇到java.lang.OutOfMemoryError: unable to create new native thread。考慮如下場景：系統總記憶體6G，堆記憶體分配了5G，永久代512M。在這種情況下，JVM佔用了5.5G記憶體，系統程序、其他使用者程序和執行緒將共用剩下的0.5G記憶體，很有可能沒有足夠的可用記憶體建立新的執行緒。如果是這種情況，考慮減小堆記憶體。
5. 減少程序數 這和減小堆記憶體原理相似。考慮如下場景：系統總記憶體32G，java程序數5個，每個程序的堆記憶體6G。在這種情況下，java程序總共佔用30G記憶體，僅剩下2G記憶體用於系統程序、其他使用者程序和執行緒，很有可能沒有足夠的可用記憶體建立新的執行緒。如果是這種情況，考慮減少每臺機器上的程序數。
6. 減小執行緒棧大小
執行緒會佔用記憶體，如果每個執行緒都佔用更多記憶體，整體上將消耗更多的記憶體。每個執行緒預設佔用記憶體大小取決於JVM實現。可以利用-Xss引數限制執行緒記憶體大小，降低總記憶體消耗。例如，JVM預設每個執行緒佔用1M記憶體，應用有500個執行緒，那麼將消耗500M記憶體空間。如果實際上256K記憶體足夠執行緒正常執行，配置-Xss256k，那麼500個執行緒將只需要消耗125M記憶體。（注意，如果-Xss設定的過低，將會產生java.lang.StackOverflowError錯誤）
實戰
1、問題背景
昨天下午突然收到運維郵件報警，顯示資料平臺伺服器cpu利用率達到了98.94%，而且最近一段時間一直持續在70%以上，看起來像是硬體資源到瓶頸需要擴容了，但仔細思考就會發現咱們的業務系統並不是一個高併發或者CPU密集型的應用，這個利用率有點太誇張，硬體瓶頸應該不會這麼快就到了，一定是哪裡的業務程式碼邏輯有問題。
2、排查思路
2.1 定位高負載程序 pid
首先登入到伺服器使用top命令確認伺服器的具體情況，根據具體情況再進行分析判斷。
通過觀察load average，以及負載評判標準（8核），可以確認伺服器存在負載較高的情況；
觀察各個程序資源使用情況，可以看出程序id為682的程序，有著較高的CPU佔比
2.2 定位具體的異常業務
這裡咱們可以使用 pwdx 命令根據 pid 找到業務程序路徑，進而定位到負責人和專案：
可得出結論：該程序對應的就是資料平臺的web服務。
2.3 定位異常執行緒及具體程式碼行
傳統的方案一般是4步：
1、top oder by with P：1040 // 首先按程序負載排序找到 maxLoad(pid)
2、top -Hp 程序PID：1073 // 找到相關負載 執行緒PID
3、printf “0x%x ”執行緒PID：0x431 // 將執行緒PID轉換為 16進位制，為後面查詢 jstack 日誌做準備
4、jstack 程序PID | vim +/十六進位制執行緒PID - // 例如：jstack 1040|vim +/0x431 -
但是對於線上問題定位來說，分秒必爭，上面的 4 步還是太繁瑣耗時了，之前介紹過淘寶的oldratlee 同學就將上面的流程封裝為了一個工具：show-busy-java-threads.sh，可以很方便的定位線上的這類問題：
可得出結論：是系統中一個時間工具類方法的執行cpu佔比較高，定位到具體方法後，檢視程式碼邏輯是否存在效能問題。
※ 如果線上問題比較緊急，可以省略 2.1、2.2 直接執行 2.3，這裡從多角度剖析只是為了給大家呈現一個完整的分析思路。
3、根因分析
經過前面的分析與排查，最終定位到一個時間工具類的問題，造成了伺服器負載以及cpu使用率的過高。
- 異常方法邏輯：是把時間戳轉成對應的具體的日期時間格式；
- 上層呼叫：計算當天凌晨至當前時間所有秒數，轉化成對應的格式放入到set中返回結果；
- 邏輯層：對應的是資料平臺實時報表的查詢邏輯，實時報表會按照固定的時間間隔來，並且在一次查詢中有多次（n次）方法呼叫。
那麼可以得到結論，如果現在時間是當天上午10點，一次查詢的計算次數就是 10*60*60*n次=36,000*n次計算，而且隨著時間增長，越接近午夜單次查詢次數會線性增加。由於實時查詢、實時報警等模組大量的查詢請求都需要多次呼叫該方法，導致了大量CPU資源的佔用與浪費。
4、解決方案
定位到問題之後，首先考慮是要減少計算次數，優化異常方法。排查後發現，在邏輯層使用時，並沒有使用該方法返回的set集合中的內容，而是簡單的用set的size數值。確認邏輯後，通過新方法簡化計算（當前秒數-當天凌晨的秒數），替換呼叫的方法，解決計算過多的問題。上線後觀察伺服器負載和cpu使用率，對比異常時間段下降了30倍，恢復至正常狀態，至此該問題得已解決。
5、總結
- 在編碼的過程中，除了要實現業務的邏輯，也要注重程式碼效能的優化。一個業務需求，能實現，和能實現的更高效、更優雅其實是兩種截然不同的工程師能力和境界的體現，而後者也是工程師的核心競爭力。
- 在程式碼編寫完成之後，多做 review，多思考是不是可以用更好的方式來實現。
- 線上問題不放過任何一個小細節！細節是魔鬼，技術的同學需要有刨根問題的求知慾和追求卓越的精神，只有這樣，才能不斷的成長和提升。