建站
咨詢
售后
建站咨詢
新聞中心
臨近月底，用戶量上來，發(fā)現(xiàn)業(yè)務進程頻繁從Eureka上掉下來，觀察后發(fā)現(xiàn)掉下來前進程CPU一直占用比較高。排查得知服務器的Java進程CPU占用高導致的網(wǎng)頁請求超時。隨后進行了如下排查修復。
一、發(fā)現(xiàn)問題的系統(tǒng)檢查：
一個管理平臺門戶網(wǎng)頁進統(tǒng)計頁面提示請求超時，隨進服務器操作系統(tǒng)檢查load average超過4負載很大，PID為7163的進程占用到了800%多。
二、定位故障
根據(jù)這種故障的一般處理思路，先找出問題進程內(nèi)CPU占用率高的線程，再通過線程棧信息找出該線程當時在運行的問題代碼段，操作如下：
２.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、確認表中數(shù)據(jù)量，發(fā)現(xiàn)表中已經(jīng)有將近300萬條數(shù)據(jù)，判斷問題是查詢時間過長導致的，使用的命令如下：
use databases_name；
select count(1) from table_name；
2.4.4、確認表是否有索引,發(fā)現(xiàn)表未創(chuàng)建索引；
show create table table_name\G
三、確認及處理問題：
詢問了研發(fā)表的數(shù)據(jù)是否重要，確認不重要，檢查字段有時間字段，根據(jù)時間確認只留一個月的數(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進程詳細信息的操作，確認是由數(shù)據(jù)庫問題導致的原因，并對數(shù)據(jù)庫進行了清理并創(chuàng)建了索引。
五、其他：
在處理問題后，又查詢了一下數(shù)據(jù)庫相關問題的優(yōu)化，有方案說在mysql配置文件中添加innodb_buffer_pool_size參數(shù)也可以優(yōu)化查詢查詢時間，但該參數(shù)的意義把數(shù)據(jù)放到內(nèi)存了，也就是說如果數(shù)據(jù)更新了，還會導致buffer失效，通常的優(yōu)化方法還是添加索引。該方法添加參數(shù)具體如下：
innodb_buffer_pool_size=4G
當前題目：Java進程CPU占用高導致的網(wǎng)頁請求超時的故障排查
瀏覽路徑：http://www.5511xx.com/article/djhjedo.html
