臨近月底，用戶量上來，發(fā)現(xiàn)業(yè)務(wù)進程頻繁從Eureka上掉下來，觀察后發(fā)現(xiàn)掉下來前進程CPU一直占用比較高。排查得知服務(wù)器的Java進程CPU占用高導(dǎo)致的網(wǎng)頁請求超時。隨后進行了如下排查修復(fù)。

一、發(fā)現(xiàn)問題的系統(tǒng)檢查：

一個管理平臺門戶網(wǎng)頁進統(tǒng)計頁面提示請求超時，隨進服務(wù)器操作系統(tǒng)檢查load average超過4負(fù)載很大，PID為7163的進程占用到了800%多。

二、定位故障

根據(jù)這種故障的一般處理思路，先找出問題進程內(nèi)CPU占用率高的線程，再通過線程棧信息找出該線程當(dāng)時在運行的問題代碼段，操作如下：

２.1、根據(jù)思路查看高占用的“進程中”占用高的“線程”，追蹤發(fā)現(xiàn)7163的進程中16298的線程占用較高，使用命令：

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

顯示結(jié)果：

2.2、將16298的線程ID轉(zhuǎn)換為16進制的線程ID。

printf "%x\n" 16298
3faa

2.3、通過jvm的jstack查看進程信息，發(fā)現(xiàn)是調(diào)用數(shù)據(jù)庫的問題。

jstack 7163 | grep "3faa" -A 30

顯示結(jié)果： 2.4、既然是數(shù)據(jù)庫的問題就檢查數(shù)據(jù)庫，思路是先打印了所有在跑的數(shù)據(jù)庫線程，檢查后發(fā)現(xiàn)跟進情況找到問題表：

2.4.1、打印mysql現(xiàn)有進程信息，并把信息生成log文件，使用的命令如下：

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

2.4.2、過濾log文件,發(fā)現(xiàn)查詢最多的表，使用的命令如下：

grep Query mysql_full_process.log

2.4.3、確認(rèn)表中數(shù)據(jù)量，發(fā)現(xiàn)表中已經(jīng)有將近300萬條數(shù)據(jù)，判斷問題是查詢時間過長導(dǎo)致的，使用的命令如下：

use databases_name；
select count(1) from table_name；

2.4.4、確認(rèn)表是否有索引,發(fā)現(xiàn)表未創(chuàng)建索引；

show create table table_name\G

三、確認(rèn)及處理問題：

詢問了研發(fā)表的數(shù)據(jù)是否重要，確認(rèn)不重要，檢查字段有時間字段，根據(jù)時間確認(rèn)只留一個月的數(shù)據(jù)，操作如下：

3.1、清理數(shù)據(jù)只保留一個月的數(shù)據(jù)，清理后數(shù)據(jù)只剩下4000多，使用命令如下；

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

3.2、由于表未加索引，所以給表創(chuàng)建索引，使用命令如下：

alter table table_name add index (device_uuid);

3.3、檢查索引是否創(chuàng)建，已經(jīng)有device_uuid的索引。

show create table table_name;

四、結(jié)果：

處理后進程的CPU占用到了40%，本次排查主要用到了jvm進程查看及dump進程詳細(xì)信息的操作，確認(rèn)是由數(shù)據(jù)庫問題導(dǎo)致的原因，并對數(shù)據(jù)庫進行了清理并創(chuàng)建了索引。

五、其他：

在處理問題后，又查詢了一下數(shù)據(jù)庫相關(guān)問題的優(yōu)化，有方案說在mysql配置文件中添加innodb_buffer_pool_size參數(shù)也可以優(yōu)化查詢查詢時間，但該參數(shù)的意義把數(shù)據(jù)放到內(nèi)存了，也就是說如果數(shù)據(jù)更新了，還會導(dǎo)致buffer失效，通常的優(yōu)化方法還是添加索引。該方法添加參數(shù)具體如下：

innodb_buffer_pool_size=4G

本文名稱：Java進程CPU占用高導(dǎo)致的網(wǎng)頁請求超時的故障排查
文章路徑：http://uogjgqi.cn/article/djhjedo.html