前言

大家都知道服務(wù)器在大促期間由于流量的增加勢(shì)必導(dǎo)致機(jī)器的cpu與load變高，本文將與大家一起鞏固cpu和load的概念，為今年各種大促做準(zhǔn)備的同時(shí)也是增加自己的技能儲(chǔ)備。

不過(guò)cpu和load這塊真的還是很需要積累的，筆者經(jīng)驗(yàn)尚淺，感覺(jué)還是有許多寫(xiě)得不到位或不恰當(dāng)?shù)牡胤剑绻绣e(cuò)誤，希望大家可以幫助指正。

一、top命令

既然說(shuō)了cpu和load，那總需要監(jiān)控吧，沒(méi)有監(jiān)控就不知道cpu和load，后面的一切也就無(wú)從談起了。

top命令是最常見(jiàn)的查看cpu和load的命令，拿我自己虛擬機(jī)上裝的ubuntu系統(tǒng)執(zhí)行一下top命令（默認(rèn)3秒刷1次，-d可指定刷新時(shí)間）：

做了一張表格比較詳細(xì)地解釋了每一部分的含義，其中重要屬性做了標(biāo)紅加粗：

內(nèi)存與SWAP輸出格式是一樣的，因此放在了一起寫(xiě)。

二、cpu如何計(jì)算

當(dāng)我們執(zhí)行top命令的時(shí)候，看到里面的值（主要是cpu和load）是一直在變的，因此有必要簡(jiǎn)單了解一下Linux系統(tǒng)中cpu的計(jì)算方式。

cpu分為系統(tǒng)cpu和進(jìn)程、線程cpu，系統(tǒng)cpu的統(tǒng)計(jì)值位于/proc/stat下（以下的截圖未截全）：

cpu、cpu0后面的這些數(shù)字都和前面的us、sy、ni這些對(duì)應(yīng)，具體哪個(gè)對(duì)應(yīng)哪個(gè)值不重要，感興趣的可以網(wǎng)上查一下文檔。

進(jìn)程cpu的統(tǒng)計(jì)值位于/proc/{pid}/stat下：

線程cpu的統(tǒng)計(jì)值位于/proc/{pid}/task/{threadId}/stat下： 

這里面的所有值都是從系統(tǒng)啟動(dòng)時(shí)間到當(dāng)前時(shí)間的一個(gè)值。因此，對(duì)于cpu的計(jì)算的做法是，采樣兩個(gè)足夠短的時(shí)間t1、t2：

•  將t1的所有cpu使用情況求和，得到s1；
•  將t2的所有cpu使用情況求和，得到s2；
•  s2 - s1得到這個(gè)時(shí)間間隔內(nèi)的所有時(shí)間totalCpuTime；
•  第一次的空閑idle1 - 第二次的空閑idle2，獲取采樣時(shí)間內(nèi)的空閑時(shí)間；
•  cpu使用率 = 100 * (totalCpuTime - idle) / totalCpuTime。

其他時(shí)間例如us、sy、ni都是類(lèi)似的計(jì)算方式，總結(jié)起來(lái)說(shuō)，cpu這個(gè)值反應(yīng)的是某個(gè)采樣時(shí)間內(nèi)的cpu使用情況。因此有時(shí)候cpu很高，但是打印線程堆棧出來(lái)發(fā)現(xiàn)高cpu的線程在查詢數(shù)據(jù)庫(kù)等待中，不要覺(jué)得奇怪，因?yàn)閏pu統(tǒng)計(jì)的是采樣時(shí)間內(nèi)的數(shù)據(jù)。

假設(shè)top觀察某段時(shí)間用戶空間cpu一直很高，那么意味著這段時(shí)間用戶的程序一直在占據(jù)著cpu做事情。

三、對(duì)load的理解

關(guān)于load的含義，其實(shí)有些文章把它跟行車(chē)過(guò)橋聯(lián)系在一起是比較恰當(dāng)和好理解的：

一個(gè)單核的處理器可以形象得比喻成一條單車(chē)道，車(chē)輛依次行駛在這條單車(chē)道上，前車(chē)駛過(guò)之后后車(chē)才可以行駛。

如果前面沒(méi)有車(chē)輛，那么你順利通過(guò)；如果車(chē)輛眾多，那么你需要等待前車(chē)通過(guò)之后才可以通過(guò)。

因此，需要些特定的代號(hào)表示目前的車(chē)流情況，例如：

•  等于0.00，表示目前橋面上沒(méi)有任何的車(chē)流。實(shí)際上這種情況0.00和1.00之間是相同的，總而言之很通暢，過(guò)往的車(chē)輛可以絲毫不用等待的通過(guò)；
•  等于1.00，表示剛好是在這座橋的承受范圍內(nèi)。這種情況不算糟糕，只是車(chē)流會(huì)有些堵，不過(guò)這種情況可能會(huì)造成交通越來(lái)越慢；
•  大于1.00，那么說(shuō)明這座橋已經(jīng)超出負(fù)荷，交通嚴(yán)重的擁堵。那么情況有多糟糕? 例如2.00的情況說(shuō)明車(chē)流已經(jīng)超出了橋所能承受的一倍，那么將有多余過(guò)橋一倍的車(chē)輛正在焦急的等待。

但是比喻終歸是比喻，從比喻中我們了解了，load表示的是系統(tǒng)的一個(gè)能力，但是我們卻不知道什么樣的任務(wù)會(huì)被歸到load的計(jì)算中。關(guān)于具體怎么樣的任務(wù)會(huì)被歸到load的計(jì)算中，可以使用man uptime命令看一下Linux對(duì)于load的解釋?zhuān)?/p>

大致意思就是說(shuō)，系統(tǒng)load是處于運(yùn)行狀態(tài)或者不可中斷狀態(tài)的進(jìn)程的平均數(shù)（標(biāo)紅部分表示被算入load的內(nèi)容）。一個(gè)處于運(yùn)行狀態(tài)的進(jìn)程表示正在使用cpu或者等待使用cpu，一個(gè)不可中斷狀態(tài)的進(jìn)程表示正在等待IO，例如磁盤(pán)IO。load的平均值通過(guò)3個(gè)時(shí)間間隔來(lái)展示，就是我們看到的1分鐘、5分鐘、15分鐘，load值和cpu核數(shù)有關(guān)，單核cpu的load=1表示系統(tǒng)一直處在負(fù)載狀態(tài)，但是4核cpu的load=1表示系統(tǒng)有75%的空閑。

特別注意，load指的是所有核的平均值，這和cpu的值是有區(qū)別的。

還有一個(gè)重要的點(diǎn)是，查了資料發(fā)現(xiàn)，雖然上面一直強(qiáng)調(diào)的是"進(jìn)程"，但是進(jìn)程中的線程數(shù)也是會(huì)被當(dāng)作不同的進(jìn)程來(lái)計(jì)算的，假如一個(gè)進(jìn)程產(chǎn)生1000個(gè)線程同時(shí)運(yùn)行，那運(yùn)行隊(duì)列的長(zhǎng)度就是1000，load average就是1000。

四、請(qǐng)求數(shù)和load的關(guān)系

之前我自己一直有個(gè)誤區(qū)：當(dāng)成千上萬(wàn)的請(qǐng)求過(guò)來(lái)，且在排隊(duì)的時(shí)候，后面的請(qǐng)求得不到處理，load值必然會(huì)升高。認(rèn)真思考之后，這個(gè)觀點(diǎn)可真是大錯(cuò)特錯(cuò)，因此特別作為一段寫(xiě)一下，和大家分享。

以Redis為例，我們都知道Redis是單線程模型的，這意味著同一時(shí)間可以有無(wú)數(shù)個(gè)請(qǐng)求過(guò)來(lái)，但是同一時(shí)間只有一個(gè)命令會(huì)被處理。

圖片來(lái)源：https://www.processon.com/view/5c2ddab0e4b0fa03ce89d14f

單獨(dú)的一條線程接到就緒的命令之后，會(huì)將命令轉(zhuǎn)給事件分發(fā)器，事件分發(fā)器根據(jù)命令的類(lèi)型執(zhí)行對(duì)應(yīng)的命令處理邏輯。由于只有一條線程，只要后面排隊(duì)的命令足夠多到讓這條線程一個(gè)接一個(gè)不停地處理命令，那么load表現(xiàn)就等于1。

整個(gè)過(guò)程中，回看load這個(gè)值，它和請(qǐng)求數(shù)沒(méi)有任何關(guān)系，真正和load相關(guān)的是工作線程數(shù)量，main線程是工作線程、Timer是工作線程、GC線程也是工作線程，load是以線程/進(jìn)程作為統(tǒng)計(jì)指標(biāo)，無(wú)論請(qǐng)求數(shù)是多少，最終都需要線程去處理，而工作線程的處理性能直接決定了最終的load值。

舉個(gè)例子，假設(shè)一個(gè)服務(wù)中有一個(gè)線程池，線程池中線程數(shù)量固定為64：

•  正常來(lái)說(shuō)一個(gè)任務(wù)執(zhí)行時(shí)間為10ms，線程拿到任務(wù)10ms處理完，很快回歸線程池等待下一個(gè)任務(wù)到來(lái)，自然很少有處于運(yùn)行狀態(tài)或者等待IO的線程，從一個(gè)統(tǒng)計(jì)周期來(lái)看load表現(xiàn)為很低；
•  某段時(shí)間由于系統(tǒng)問(wèn)題，一個(gè)任務(wù)10s都處理不完，相當(dāng)于線程一直在處理任務(wù)，在load的統(tǒng)計(jì)周期里面就體現(xiàn)出的值=64（不考慮這64條線程外的場(chǎng)景）。

因此，總而言之，搞清楚load值和請(qǐng)求數(shù)、線程數(shù)的關(guān)系非常重要，想清楚這些才能正確地進(jìn)行下一步的工作。

五、load高、cpu高的問(wèn)題排查思路

首先拋出一個(gè)觀點(diǎn)：cpu高不是問(wèn)題，由cpu高引起的load高才是問(wèn)題，load是判斷系統(tǒng)能力指標(biāo)的依據(jù)。

為什么這么說(shuō)呢，以單核cpu為例，當(dāng)我們?nèi)粘pu在20%、30%的時(shí)候其實(shí)對(duì)cpu資源是浪費(fèi)的，這意味著絕大多數(shù)時(shí)候cpu并沒(méi)有在做事，理論上來(lái)說(shuō)一個(gè)系統(tǒng)極限cpu利用率可以達(dá)到100%，這意味著cpu完全被利用起來(lái)了處理計(jì)算密集型任務(wù)，例如for循環(huán)、md5加密、new對(duì)象等等。但是實(shí)際不可能出現(xiàn)這種情況，因?yàn)閼?yīng)用程序中不消耗cpu的IO不存在是幾乎不可能的，例如讀取數(shù)據(jù)庫(kù)或者讀取文件，因此cpu不是越高越好，通常75%是一個(gè)需要引起警戒的經(jīng)驗(yàn)值。

注意前面提到的是"引起警戒"，意味著cpu高不一定是問(wèn)題，但是需要去看一下，尤其是日常的時(shí)候，因?yàn)橥ǔＨ粘Ａ髁坎淮?，cpu是不可能打到這么高的。如果只是普通的代碼中確實(shí)在處理正常業(yè)務(wù)那沒(méi)問(wèn)題，如果代碼里面出現(xiàn)了死循環(huán)（例如JDK1.7中經(jīng)典的HashMap擴(kuò)容引發(fā)的死循環(huán)問(wèn)題），那么幾條線程一直占著cpu，最后就會(huì)造成load的增高。

在一個(gè)Java應(yīng)用中，排查cpu高的思路通常比較簡(jiǎn)單，有比較固定的做法：

•  ps -ef | grep java，查詢Java應(yīng)用的進(jìn)程pid；
•  top -H -p pid，查詢占用cpu最高的線程pid；
•  將10進(jìn)制的線程pid轉(zhuǎn)成16進(jìn)制的線程pid，例如2000=0x7d0；
•  jstack 進(jìn)程pid | grep -A 20 '0x7d0'，查找nid匹配的線程，查看堆棧，定位引起高cpu的原因。

網(wǎng)上有很多文章寫(xiě)到這里就停了，實(shí)踐過(guò)程中并不是這樣。因?yàn)閏pu是時(shí)間段內(nèi)的統(tǒng)計(jì)值、jstack是一個(gè)瞬時(shí)堆棧只記錄瞬時(shí)狀態(tài)，兩個(gè)根本不是一個(gè)維度的事，因此完全有可能從打印出來(lái)的堆棧行號(hào)中看到代碼停留在以下地方：

•  不消耗cpu的網(wǎng)絡(luò)IO；
•  for (int i = 0, size = list.size(); i < size; i++) {...}；
•  調(diào)用native方法。

如果完全按照上面那一套步驟做的話碰到這種情況就傻眼了，冥思苦想半天卻不得其解，根本不明白為什么這種代碼會(huì)導(dǎo)致高cpu。針對(duì)可能出現(xiàn)的這種情況，實(shí)際排查問(wèn)題的時(shí)候jstack建議打印5次至少3次，根據(jù)多次的堆棧內(nèi)容，再結(jié)合相關(guān)代碼段進(jìn)行分析，定位高cpu出現(xiàn)的原因，高cpu可能是代碼段中某個(gè)bug導(dǎo)致的而不是堆棧打印出來(lái)的那幾行導(dǎo)致的。

另外，cpu高的情況還有一種可能的原因，假如一個(gè)4核cpu的服務(wù)器我們看到總的cpu達(dá)到了100%+，按1之后觀察每個(gè)cpu的us，只有一個(gè)達(dá)到了90%+，其他都在1%左右（下圖只是演示top按1之后的效果并非真實(shí)場(chǎng)景）：

這種情況下可以重點(diǎn)考慮是不是頻繁FullGC引起的。因?yàn)槲覀冎繤ullGC的時(shí)候會(huì)有Stop The World這個(gè)動(dòng)作，多核cpu的服務(wù)器，除了GC線程外，在Stop The World的時(shí)候都是會(huì)掛起的，直到Stop The World結(jié)束。以幾種老年代垃圾收集器為例：

•  Serial Old收集器，全程Stop The World；
•  Parallel Old收集器，全程Stop The World；
•  CMS收集器，它在初始標(biāo)記與并發(fā)標(biāo)記兩個(gè)過(guò)程中，為了準(zhǔn)確標(biāo)記出需要回收的對(duì)象，都會(huì)Stop The World，但是相比前兩種大大減少了系統(tǒng)停頓時(shí)間。

無(wú)論如何，當(dāng)真正發(fā)生Stop The World的時(shí)候，就會(huì)出現(xiàn)GC線程在占用cpu工作而其他線程掛起的情況，自然表現(xiàn)也就為某個(gè)cpu的us很高而且他cpu的us很低。

針對(duì)FullGC的問(wèn)題，排查思路通常為：

•  ps -ef | grep java，查詢Java應(yīng)用的進(jìn)程pid；
•  jstat -gcutil pid 1000 1000，每隔1秒打印一次內(nèi)存情況共打印1000次，觀察老年代（O）、MetaSpace（MU）的內(nèi)存使用率與FullGC次數(shù)；
•  確認(rèn)有頻繁的FullGC的發(fā)生，查看GC日志，每個(gè)應(yīng)用GC日志配置的路徑不同；
•  jmap -dump:format=b,file=filename pid，保留現(xiàn)場(chǎng)；
•  重啟應(yīng)用，迅速止血，避免引起更大的線上問(wèn)題；
•  dump出來(lái)的內(nèi)容，結(jié)合MAT分析工具分析內(nèi)存情況，排查FullGC出現(xiàn)的原因。

如果FullGC只是發(fā)生在老年代區(qū)，比較有經(jīng)驗(yàn)的開(kāi)發(fā)人員還是容易發(fā)現(xiàn)問(wèn)題的，一般都是一些代碼bug引起的。MetaSpace發(fā)生的FullGC經(jīng)常會(huì)是一些詭異、隱晦的問(wèn)題，很多和引入的第三方框架使用不當(dāng)有關(guān)或者就是第三方框架有bug導(dǎo)致的，排查起來(lái)就很費(fèi)時(shí)間。

那么頻繁FullGC之后最終會(huì)導(dǎo)致load如何變化呢？這個(gè)我沒(méi)有驗(yàn)證過(guò)和看過(guò)具體數(shù)據(jù)，只是通過(guò)理論分析，如果所有線程都是空閑的，只有GC線程在一直做FullGC，那么load最后會(huì)趨近于1。但是實(shí)際不可能，因?yàn)槿绻麤](méi)有其他線程在運(yùn)行，怎么可能導(dǎo)致頻繁FullGC呢。所以，在其他線程處理任務(wù)的情況下Stop The World之后，cpu掛起，任務(wù)得不到處理，更大可能的是load會(huì)一直升高。

最后順便提一句，前面一直在講FullGC，頻繁的YoungGC也是會(huì)導(dǎo)致load升高的，之前看到過(guò)的一個(gè)案例是，Object轉(zhuǎn)xml，xml轉(zhuǎn)Object，代碼中每處都new XStream()去進(jìn)行xml序列化與反序列化，回收速度跟不上new的速度，YoungGC次數(shù)陡增。

六、load高、cpu低的問(wèn)題排查思路

關(guān)于load的部分，我們可以看到會(huì)導(dǎo)致load高的幾個(gè)因素：

•  線程正在使用cpu；
•  線程正在等待使用cpu；
•  線程在執(zhí)行不可被打斷的IO操作。

既然cpu不高，load高，那么線程要么在進(jìn)行io要么在等待使用cpu。不過(guò)對(duì)于后者"等待使用cpu"我這里存疑，比如線程池里面10個(gè)線程，任務(wù)來(lái)的很慢，每次只會(huì)用到1個(gè)線程，那么9個(gè)線程都是在等待使用cpu，但是這9個(gè)線程明顯是不會(huì)占據(jù)系統(tǒng)資源的，因此我認(rèn)為自然也不會(huì)消耗cpu，所以這個(gè)點(diǎn)不考慮。

因此，在cpu不高的情況下假如load高，大概率io高才是罪魁禍?zhǔn)祝鼘?dǎo)致的是任務(wù)一直在跑，遲遲處理不完，線程無(wú)法回歸線程池中。首先簡(jiǎn)單講講磁盤(pán)io，既然wa表示的是磁盤(pán)io等待cpu的百分比，那么我們可以看下wa確認(rèn)下是不是磁盤(pán)io導(dǎo)致的：

如果是，那么按照cpu高同樣的方式打印一下堆棧，查看文件io的部分進(jìn)行分析，排查原因，例如是不是多線程都在讀取本地一個(gè)超大的文件到內(nèi)存。

磁盤(pán)io導(dǎo)致的load高，我相信這畢竟是少數(shù)，因?yàn)镴ava語(yǔ)言的特點(diǎn)，應(yīng)用程序更多的高io應(yīng)當(dāng)是在處理網(wǎng)絡(luò)請(qǐng)求，例如：

•  從數(shù)據(jù)庫(kù)中獲取數(shù)據(jù)；
•  從Redis中獲取數(shù)據(jù)；
•  調(diào)用Http接口從支付寶獲取數(shù)據(jù)；
•  通過(guò)dubbo獲取某服務(wù)中的數(shù)據(jù)。

針對(duì)這種情況，我覺(jué)得首先我們應(yīng)該對(duì)整個(gè)系統(tǒng)架構(gòu)的依賴比較熟悉，例如我畫(huà)一個(gè)草圖：

對(duì)依賴方的調(diào)用任何一個(gè)出現(xiàn)比較高的耗時(shí)都會(huì)增加自身系統(tǒng)的load，出現(xiàn)load高的建議排查方式為：

•  查日志，無(wú)論是HBase、MySql、Redis調(diào)用還是通過(guò)http、dubbo調(diào)用接口，調(diào)用超時(shí)，拿連接池中的連接超時(shí)，通常都會(huì)有錯(cuò)誤日志拋出來(lái)，只要系統(tǒng)里面沒(méi)有捕獲異常之后不打日志直接吞掉一般都能查到相關(guān)的異常；
•  對(duì)于dubbo、http的調(diào)用，建議做好監(jiān)控埋點(diǎn)，輸出接口名、方法入?yún)ⅲ刂拼笮。?、是否成功、調(diào)用時(shí)長(zhǎng)等必要參數(shù)，有些時(shí)候可能沒(méi)有超時(shí)，但是調(diào)用2秒、3秒一樣會(huì)導(dǎo)致load升高，所以這種時(shí)候需要查看方法調(diào)用時(shí)長(zhǎng)進(jìn)行下一步動(dòng)作。

如果上面的步驟還是沒(méi)用或者沒(méi)有對(duì)接口調(diào)用做埋點(diǎn)，那么還是萬(wàn)能的打印堆棧吧，連續(xù)打印五次十次，看一下每次的堆棧是否大多都指向同一個(gè)接口的調(diào)用，網(wǎng)絡(luò)io的話，堆棧的最后幾行一般都有at java.net.SocketInputStream.read(SocketInputStream.java:129)。

七、Java應(yīng)用load高的幾種原因總結(jié)

前面說(shuō)了這么多，這里總結(jié)一下load高可能的一些原因：

•  死循環(huán)或者不合理的大量循環(huán)操作，如果不是循環(huán)操作，按照現(xiàn)代cpu的處理速度來(lái)說(shuō)處理一大段代碼也就一會(huì)會(huì)兒的事，基本對(duì)能力無(wú)消耗；
•  頻繁的YoungGC；
•  頻繁的FullGC；
•  高磁盤(pán)IO；
•  高網(wǎng)絡(luò)IO。

系統(tǒng)load高通常都是由于某段發(fā)布的代碼有bug或者引入某些第三方j(luò)ar而又使用不合理導(dǎo)致的，因此注意首先區(qū)分load高，是由于cpu高導(dǎo)致的還是io高導(dǎo)致的，根據(jù)不同的場(chǎng)景采取不同定位問(wèn)題的方式。

當(dāng)束手無(wú)策時(shí)，jstack打印堆棧多分析分析吧，或許能靈光一現(xiàn)能找到錯(cuò)誤原因。

結(jié)語(yǔ)

先有理論，把理論想透了，實(shí)戰(zhàn)碰到問(wèn)題的時(shí)候才能頭腦清楚。

坦白講，cpu和load高排查是一個(gè)很偏實(shí)戰(zhàn)的事情，這方面我還也有很長(zhǎng)一條路需要走，身邊在這塊經(jīng)驗(yàn)比我豐富的同事多得很。很多人問(wèn)過(guò)我，項(xiàng)目比較簡(jiǎn)單，根本沒(méi)有這種線上問(wèn)題需要我去排查怎么辦？這個(gè)問(wèn)題只能說(shuō)，平時(shí)多積累、多實(shí)戰(zhàn)是唯一途徑，假如沒(méi)有實(shí)戰(zhàn)機(jī)會(huì)，那么推薦三種方式：

•  自己通過(guò)代碼模擬各種異常，例如FullGC、死鎖、死循環(huán)，然后利用工具去查，可能比較簡(jiǎn)單，但是萬(wàn)丈高樓平地起，再?gòu)?fù)雜的東西都是由簡(jiǎn)單的變化過(guò)來(lái)的；
•  多上服務(wù)器上敲敲top、sar、iostat這些命令，熟記每個(gè)命令的作用及輸出參數(shù)的含義；
•  去網(wǎng)上找一下其他人處理FullGC、CPU高方法的文章，站在巨人的肩膀上，看看前人走過(guò)的路，總結(jié)記錄一些實(shí)用的點(diǎn)。

當(dāng)真的有實(shí)戰(zhàn)機(jī)會(huì)來(lái)的時(shí)候把握住，即使是同事排查的問(wèn)題，也可以在事后搞清楚問(wèn)題的來(lái)龍去脈，久而久之自然這方面的能力就會(huì)提高上去。