一、發現問題的系統檢查

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

二、定位故障

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

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

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

顯示結果：

將16298的線程ID轉換為16進制的線程ID。

printf "%x\n" 16298 3faa

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

jstack 7163 | grep "3faa" -A 30

顯示結果：

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

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

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

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

grep Query mysql_full_process.log

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

use databases_name； select count(1) from table_name；

確認表是否有索引，發現表未創建索引；

show create table table_name\G

三、確認及處理問題

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

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

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

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

alter table table_name add index (device_uuid);

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

show create table table_name;

四、結果

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

五、其他

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

總結

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

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