一、指標(biāo)
通常應(yīng)用服務(wù)性能關(guān)注以下兩方面的指標(biāo)：
下面將主要是基于CPU指標(biāo)進(jìn)行實驗?zāi)M分析，下面是一些命令下，cpu指標(biāo)：
1、top 命令下個字段含義，參考：http://www.itdecent.cn/p/078ed7895b0f
2、vmstat 命令：
us：用戶占用CPU的百分比
sy：系統(tǒng)(內(nèi)核和中斷)占用CPU的百分比
id：CPU空閑的百分比
二、實驗
1、環(huán)境：Linux 2.6.32-696.18.7.el6.x86_64
2、流程：通過Jmeter 對服務(wù)接口進(jìn)行壓測，模擬高并發(fā)訪問，從而使CPU負(fù)載飆升。
3、接口代碼：
public PlainResult<String> test() throws InterruptedException{
Integer n =0;
synchronized(locka){
try{
for(;;){
if(n < Integer.MAX_VALUE){
continue;
}
n++;
}
}catch (Exception e){
log.info("報錯啦");
}
}
return ResultUtils.createSuccessResult("true");
}
4、JEMET 測試：線程數(shù)=100 ，循環(huán)調(diào)用：
三、分析
此時，用戶已經(jīng)感知服務(wù)非常的慢，作為開發(fā)人員需要定位問題出在哪，以下是基本步驟。
1、首先，我們不知道是哪方面出現(xiàn)了性能問題，因此可以先整體看下服務(wù)的性能，通過vmstat 可以獲?。?/p>
從上圖可以看出，內(nèi)存、io等無性能瓶頸，但是CPU指標(biāo)us（用戶占用CPU的百分比）非常高，幾乎接近100，id（CPU空閑的百分比）-->0，但是sy不高，另外in(系統(tǒng)中斷)和cs(上下文切換)的數(shù)值非常高，這里可以猜測是用戶應(yīng)用中有大量的線程切換。
2、jps -l 查看有哪些Java進(jìn)程：
可以看到，服務(wù)器上只有一個應(yīng)用服務(wù)，其進(jìn)程pid=24244
3、此時可用top命令可以查看具體信息：
從上圖中可以看到，進(jìn)程pid=24244一直cpu占用很高，基本可以定位到是該應(yīng)用出現(xiàn)了性能瓶頸問題。
4、jstack -l 24244 > /data/logs/retail-scrm/test/24244.log dump出該進(jìn)程下所有線程的堆棧信息.
5、使用 top -H -p 24244 進(jìn)一步找出高占用CPU的線程：
從圖中可以看出線程為30654 的一直占用著資源。
6、printf "%x" 30654 輸出對應(yīng)16進(jìn)制的線程號：77be：
7、進(jìn)入24244.log 找到對應(yīng)線程的堆棧信息：
可以看到在該方法中，獲取了一個Object對象鎖（private static Object locka = new Object();），而大量的其他線程則被阻塞等待鎖的釋放。
在找到應(yīng)用中對應(yīng)的代碼，分析其合理性即可。
以上是簡單的模擬線上可能出現(xiàn)的性能問題：主要是通過常用命令查看服務(wù)器相關(guān)指標(biāo)，并通過dump進(jìn)程相關(guān)堆棧信息來定位應(yīng)用中可能出現(xiàn)性能問題的節(jié)點。文章有不對之處，誠邀斧正，你的批評是我前進(jìn)的最大動力！
