一、測試過程中cpu過高

1、用vmstat實時監控cpu使用情況。很小的壓力AP cpu卻到了80%多，指標是不能超過60%。

vmstat 2(每二秒顯示一次系統記憶體的統計資訊)

2、分析是use cpu過高還是sys cpu過高，常見的是use cpu使用過高。

3、如果是sys cpu使用過高，先把消耗cpu最多的程序找出來（top命令），再找到該執行緒下消耗cpu過高的是哪幾個執行緒，再把該執行緒轉換成16進位制，再用jstack命令來dump執行緒棧，看這個執行緒棧在呼叫什麼東西導致use cpu過高。

①top->top -H -p pid->②printf '0x%x' tid->③stack pid | grep tid->④

jstackpid > dump01

二、記憶體溢位（堆溢位、棧溢位、持久代溢位）

1、堆記憶體溢位

1)穩定性壓測一段時間後報錯，日誌報java.lang.OutOfMemoryError.Java heap space。

2)用jmap -histo pid | head -20命令dump堆記憶體使用情況，檢視堆記憶體排名前20個物件，看是否有自己應用程式的方法，從最高的查起，如果有則檢查該方法是什麼原因造成堆記憶體溢位。

3)如果前20裡沒有自己的方法，則用jmap -dump來dump堆記憶體（jmap -dump:format=b,file=202007028.dump 105944），在用jvisualvm分析dump下來的堆記憶體，分析匯出記憶體溢位的方法。

4)如果應用程式的方法沒有問題，則需要修改JVM引數，修改xms，xmx，調整堆記憶體引數，一般是增加堆記憶體。

2、棧記憶體溢位

1)穩定性壓測一段時間後報錯，日誌報Java.Lang.StackOverflowError。

2)修改jvm引數，將xss引數改大，增加棧記憶體。

3)棧溢位一定是做批量操作引起的，減少批處理資料量。

3、持久代溢位

1)穩定性壓測一定時間後，日誌報Java.Lang.OutOfMenoryError.PermGen Space。

2)這種原因是由於類、方法描述、欄位描述、常量池、訪問修飾符等一些靜態變數太多，將持久代佔滿導致持久代溢位。

3)修改jvm配置，將XX:MaxPermSize=256引數調大。儘量減少靜態變數。

三、執行緒死鎖

1、容量測試壓測一段時間後，壓力工具報連線超時。

2、造成這種現象的原因很多，比如頻寬不夠，中介軟體執行緒池不夠用，資料庫連線池不夠，連線數佔滿等都會造成連線不上而報超時錯誤。

3、jstack命令dump執行緒棧，搜尋執行緒棧裡有沒有block，如果有的話就是執行緒死鎖，找到死鎖的執行緒，分析對應的程式碼。

四、資料庫死鎖

1、容量測試壓測一段時間後，報連線超時。

2、造成這種現象的原因很多，比如頻寬不夠，中介軟體執行緒池不夠用，資料庫連線池不夠，連線數佔滿等都會造成連線不上而報超時錯誤。

3、資料庫日誌中搜索block，能搜到block的話就是存在資料庫死鎖，找到日誌，檢視對應的sql，優化造成死鎖的sql。

五、資料庫連線池不釋放

1、容量測試壓測一段時間後，報連線超時。

2、造成這種現象的原因很多，比如頻寬不夠，中介軟體執行緒池不夠用，資料庫連線池不夠，連線數佔滿等都會造成連線不上而報超時錯誤。

3、去資料庫檢視應用程式到資料庫的連線有多少個（ show full processlist），假如應用程式裡面配置的資料庫連線為30，在資料庫檢視應用程式到資料庫的連線也是30，則表示連線池佔滿了。將配置改成90試試，去資料庫看如果連線到了90，則可以確定是資料庫連線池不釋放導致的。檢視程式碼，資料庫連線部分是不是有建立連線但是沒有關閉連線的情況。基本就是這種情況導致的，修改程式碼即可。

六、TPS上不去

1、壓力大的時候tps頻繁抖動，導致總tps上不去。檢視是否有fullgc（tail -f gc_mSrv1.log | grep full）。

2、pacing設定太小也會導致tps上不去，對抖動大的交易多增加點使用者即可。

3、tps抖動，單壓抖動大的交易，發現很平穩，這時懷疑是不是壓力太大導致，所以發容量的時候把壓力最大的那隻交易分到其他壓力機，然後發現tps不抖動了。注意：多臺壓力機隻影響tps抖動，不會影響伺服器的cpu。

4、看響應時間有沒有超時，看使用者數夠不夠。

七、伺服器壓力不均衡（相差1%-2%是正常的）

1、跑最優容量的時候，四臺AP只有一臺cpu超過60%，其他三臺都在60%以下。

2、檢視伺服器是否有定時任務。

3、檢視是否存在壓力機瓶頸。

4、是否存在頻寬瓶頸（區域網不存在此問題）。

5、檢視部署的版本，配置是否一樣。

6、可能別人也在用這些AP，因為同一臺物理機上有很多虛擬機器，因為別人先用，資源被別人先佔了。

八、fullgc時間太長

1、跑容量和穩定性的時候，出現報請求超時錯誤，檢視後臺日誌是fullgc了，看幾點報的錯和日誌裡fullgc的時間是否對應，fullgc會暫停整個應用程式，導致LR前端沒響應，所以報錯，這時可以減少old代記憶體，從而減少fullgc時間，減少fullgc時間就不會報錯，讓使用者幾乎感覺不到應用程式暫停。

2、四臺AP輪流著full gc（部分server fullgc，其他server也會fullgc），這時可以制定策略讓不同的server不同時fullgc，或者等夜間交易量少時寫定時任務重啟服務。