作者：榮書

來源：https://blog.51cto.com/rongshu/2426712

一、發現問題的系統檢查：
一個管理平臺門戶網頁進統計頁面提示請求超時，隨進服務器操作系統檢查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" 162983faa

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.log2.4.2、過濾log文件,發現查詢最多的表，使用的命令如下：
grep Query mysql_full_process.log2.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

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的Java进程CPU占用高导致的网页请求超时的故障排查的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。