面試官：線上服務(wù)器CPU占用率高如何排查定位問題？
國外開發(fā)者平臺 HankerRank 發(fā)布的 2018 年開發(fā)者技能調(diào)查報(bào)告中有一項(xiàng)關(guān)于"雇主最看重哪些核心能力"的調(diào)查，結(jié)果顯示如下：
排名前幾的比較受重視的能力分別為：解決問題、編程語言熟練程度、Debug、系統(tǒng)設(shè)計(jì)和性能優(yōu)化。
解決問題的能力以超高比例排名第一，這也是為什么很多面試過程中，面試官都喜歡問如下問題：
- 你這個(gè)項(xiàng)目遇到的最大挑戰(zhàn)是什么?如何解決的?
- 如果線上發(fā)生了報(bào)警你回如何排查呢?
- 你有解決過什么線上問題嗎?
- 能列舉幾個(gè)你知道的排查Linux服務(wù)器線上問題的命令嗎?
這些，都是比較常見的問題，還有一些比較具體的問題也是建議很多開發(fā)者都需要掌握的，如：
- 線上服務(wù)器Load飆高如何排查?
- 線上服務(wù)器CPU占用率高如何排查?
- 線上服務(wù)器頻繁發(fā)生Full GC如何排查?
- 線上服務(wù)器發(fā)生死鎖如何排查?
這些問題的回答，一方面考察了面試者是否具有很強(qiáng)的實(shí)戰(zhàn)經(jīng)驗(yàn)，另外一方面也能體現(xiàn)出其解決問題的能力。
毋庸置疑，作為開發(fā)人員來說，定位并解決問題的能力是至關(guān)重要的。因?yàn)橐坏┚€上發(fā)生了問題，如CPU占用率高，如果不及時(shí)解決，很容易導(dǎo)致網(wǎng)站響應(yīng)慢、服務(wù)器宕機(jī)等問題。
那么，書歸正傳，本文我們就來簡單介紹一下，如果線上服務(wù)器發(fā)生CPU占用率過高的問題時(shí)，應(yīng)該如何排查并定位問題。
1、問題發(fā)現(xiàn)
本文整理自一個(gè)真實(shí)的案例，是樓主負(fù)責(zé)的業(yè)務(wù)，在一次大促之前的壓測時(shí)發(fā)現(xiàn)了這個(gè)問題。
在每次大促之前，我們的測試人員都會對網(wǎng)站進(jìn)行壓力測試，這個(gè)時(shí)候會查看服務(wù)的cpu、內(nèi)存、load、rt、qps等指標(biāo)。
在一次壓測過程中，測試人員發(fā)現(xiàn)我們的某一個(gè)接口，在qps上升到500以后，CPU使用率急劇升高。
CPU利用率，又稱CPU使用率。顧名思義，CPU利用率是來描述CPU的使用情況的，表明了一段時(shí)間內(nèi)CPU被占用的情況。使用率越高，說明你的機(jī)器在這個(gè)時(shí)間上運(yùn)行了很多程序，反之較少。
2、問題定位
遇到這種問題，首先是登錄到服務(wù)器，看一下具體情況。
定位進(jìn)程
登錄服務(wù)器，執(zhí)行top命令，查看CPU占用情況：
- $top
- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
- 1893 admin 20 0 7127m 2.6g 38m S 181.7 32.6 10:20.26 java
top命令是Linux下常用的性能分析工具，能夠?qū)崟r(shí)顯示系統(tǒng)中各個(gè)進(jìn)程的資源占用狀況，類似于Windows的任務(wù)管理器。
通過以上命令，我們可以看到，進(jìn)程ID為1893的Java進(jìn)程的CPU占用率達(dá)到了181%，基本可以定位到是我們的Java應(yīng)用導(dǎo)致整個(gè)服務(wù)器的CPU占用率飆升。
定位線程
我們知道，Java是單進(jìn)程多線程的，那么，我們接下來看看PID=1893的這個(gè)Java進(jìn)程中的各個(gè)線程的CPU使用情況，同樣是用top命令：
- $top -Hp 1893
- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
- 4519 admin 20 0 7127m 2.6g 38m R 18.6 32.6 0:40.11 java
通過top -Hp 1893命令，我們可以發(fā)現(xiàn)，當(dāng)前1893這個(gè)進(jìn)程中，ID為4519的線程占用CPU最高。
定位代碼
通過top命令，我們目前已經(jīng)定位到導(dǎo)致CPU使用率較高的具體線程， 那么我么接下來就定位下到底是哪一行代碼存在問題。
首先，我們需要把4519這個(gè)線程轉(zhuǎn)成16進(jìn)制：
- $printf %x 4519
- 11a7
接下來，通過jstack命令，查看棧信息：
- $sudo -u admin jstack 1893 |grep -A 200 11a7
- "HSFBizProcessor-DEFAULT-8-thread-5" #500 daemon prio=10 os_prio=0 tid=0x00007f632314a800 nid=0x11a2 runnable [0x000000005442a000]
- java.lang.Thread.State: RUNNABLE
- at sun.misc.URLClassPath$Loader.findResource(URLClassPath.java:684)
- at sun.misc.URLClassPath.findResource(URLClassPath.java:188)
- at java.net.URLClassLoader$2.run(URLClassLoader.java:569)
- at java.net.URLClassLoader$2.run(URLClassLoader.java:567)
- at java.security.AccessController.doPrivileged(Native Method)
- at java.net.URLClassLoader.findResource(URLClassLoader.java:566)
- at java.lang.ClassLoader.getResource(ClassLoader.java:1093)
- at java.net.URLClassLoader.getResourceAsStream(URLClassLoader.java:232)
- at org.hibernate.validator.internal.xml.ValidationXmlParser.getInputStreamForPath(ValidationXmlParser.java:248)
- at org.hibernate.validator.internal.xml.ValidationXmlParser.getValidationConfig(ValidationXmlParser.java:191)
- at org.hibernate.validator.internal.xml.ValidationXmlParser.parseValidationXml(ValidationXmlParser.java:65)
- at org.hibernate.validator.internal.engine.ConfigurationImpl.parseValidationXml(ConfigurationImpl.java:287)
- at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:174)
- at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
- at com.test.common.util.BeanValidator.validate(BeanValidator.java:30)
通過以上代碼，我們可以清楚的看到，BeanValidator.java的第30行是有可能存在問題的。
3、問題解決
接下來就是通過查看代碼來解決問題了，我們發(fā)現(xiàn)，我們自定義了一個(gè)BeanValidator，封裝了Hibernate的Validator，然后在validate方法中，通過Validation.buildDefaultValidatorFactory().getValidator()初始化一個(gè)Validator實(shí)例，通過分析發(fā)現(xiàn)這個(gè)實(shí)例化的過程比較耗時(shí)。
我們重構(gòu)了一下代碼，把Validator實(shí)例的初始化提到方法外，在類初始化的時(shí)候創(chuàng)建一次就解決了問題。
4、總結(jié)
以上，展示了一次比較完成的線上問題定位過程。主要用到的命令有:top 、printf 和 jstack
另外，線上問題排查還可以使用Alibaba開源的工具Arthas進(jìn)行排查，以上問題，可以使用一下命令定位：
- thread -n 3 //查看cpu占比前三的線程
以上，本文介紹了如何排查線上服務(wù)器CPU使用率過高的問題，如果大家感興趣，后面可以再介紹一些關(guān)于LOAD飆高、頻繁GC等問題的排查手段。
