Java進程CPU佔用高導致的網頁請求超時的故障排查

一、發現問題的系統檢查：
　　一個管理平臺門戶網頁進統計頁面提示請求超時，隨進服務器操作系統檢查load average超過4負載很大，PID爲7163的進程佔用到了800%多。

二、定位故障
　　根據這種故障的一般處理思路，先找出問題進程內CPU佔用率高的線程，再通過線程棧信息找出該線程當時在運行的問題代碼段，操作如下：

２.1、根據思路查看高佔用的“進程中”佔用高的“線程”，追蹤發現7163的進程中16298的線程佔用較高，使用命令：

top -Hbp 7163 | awk '/java/ && $9>50'

顯示結果：

2.2、將16298的線程ID轉換爲16進制的線程ID。

printf "%x\n" 16298
3faa

2.3、通過jvm的jstack查看進程信息，發現是調用數據庫的問題。

jstack 7163 | grep "3faa" -A 30

顯示結果：

2.4、既然是數據庫的問題就檢查數據庫，思路是先打印了所有在跑的數據庫線程，檢查後發現跟進情況找到問題表：

2.4.1、打印mysql現有進程信息，並把信息生成log文件，使用的命令如下：

mysql -uroot -p -e "show full processlist" > mysql_full_process.log

2.4.2、過濾log文件,發現查詢最多的表，使用的命令如下：

grep Query mysql_full_process.log

2.4.3、確認表中數據量，發現表中已經有將近300萬條數據，判斷問題是查詢時間過長導致的，使用的命令如下：

use databases_name；
select count(1) from table_name；

2.4.4、確認表是否有索引,發現表未創建索引；

show create table table_name\G

三、確認及處理問題：
　　詢問了研發表的數據是否重要，確認不重要，檢查字段有時間字段，根據時間確認只留一個月的數據，操作如下：

3.1、清理數據只保留一個月的數據，清理後數據只剩下4000多，使用命令如下；

delete from table_name where xxxx_time < '2019-07-01 00:00:00' or xxxx_time is null;

3.2、由於表未加索引，所以給表創建索引，使用命令如下：

alter table table_name add index (device_uuid);

3.3、檢查索引是否創建，已經有device_uuid的索引。

show create table table_name;

四、結果：
　　處理後進程的CPU佔用到了40%，本次排查主要用到了jvm進程查看及dump進程詳細信息的操作，確認是由數據庫問題導致的原因，並對數據庫進行了清理並創建了索引。

五、其他：
　　在處理問題後，又查詢了一下數據庫相關問題的優化，有方案說在mysql配置文件中添加innodb_buffer_pool_size參數也可以優化查詢查詢時間，但該參數的意義把數據放到內存了，也就是說如果數據更新了，還會導致buffer失效，通常的優化方法還是添加索引。該方法添加參數具體如下：
innodb_buffer_pool_size=4G