CPU佔用高系統反應慢之問題定位

今天在看到公司羣裏有關於測試反應測試服務器比較卡，調用調用超時，響應很慢，成功率低的問題，而後想着去處理這個問題。

本着開發的精神，摒棄網管的水平，尋找問題的根源。

主要從以下幾個方面入手：

1：查詢服務器硬件等狀況（通常不會）

2：查看網絡是否正常，是否由於網絡的緣由致使服務器緩慢，是否nginx/apache類的代理緣由。

3：查詢服務器日誌是否正常，若是是Tomcat，則看下容器日誌是否正常，應用日誌是否正常等

4：查詢服務器是否正常，本文講述的是服務器查看方面的狀況

排查方法：

一： top命令查詢哪些進程致使了服務器處理器及內存使用狀況

　　top命令是Linux下經常使用的性能分析工具，可以實時顯示系統中各個進程的資源佔用情況，相似於Windows的任務管理器。

　　top是一個動態顯示過程,便可以經過用戶按鍵來不斷刷新當前狀態.若是在前臺執行該命令,它將獨佔前臺,直到用戶終止該程序爲止.

　　比較準確的說,top命令提供了實時的對系統處理器的狀態監視.它將顯示系統中CPU最「敏感」的任務列表.該命令能夠按CPU使用.內存使用和執行時間對任務進行排序；

　　並且該命令的不少特性均可以經過交互式命令或者在我的定製文件中進行設定。 

  一：執行命令，查詢哪些進程致使了服務器CPU高或者內存高等問題（下圖只是寫博客的時候，從服務器中截圖，非實時排查的時候的圖，圖僅供參考）

        查詢過程當中，能夠經過此命令，排查是CPU高仍是內存高。

        若是是CPU高，則看對應的CPU高的進程問題的線程列表。

        若是是內存使用高，則看對應內存高的進程的線程列表，定位問題。

top

二：使用top -Hp  pid查詢具體的進程中的線程使用狀況（本次主要講解CPU的問題）

       假使上圖中的PID爲529的JAVA進程佔用CPU 比較高，那麼咱們就須要查詢下這個進程下哪一個線程佔用了高。

       能夠經過命令top -Hp 529來查詢線程列表，列表以下

假如上圖中，看到859的線程佔用的CPU很高，那麼能夠看到 PID是 529 ，CPU使用率，內存使用率等

使用在線工具，直接轉換 859 轉換 爲35b  在線進制轉換工具 

三：殺JavaCore找出對應的線程信息

獲取javacore和heapdump文件的方法有兩種：
第一種：
系統發生內存溢出，在目錄下會生產javacore和heapdump文件生成（最多見的一種）

第二種：
手動觸發生成javacore和heapdump文件

kill -3 859

 在某些系統中，可使用kill -3 來殺進程(部分系統或者容器不支持)，獲取到JavaCore線程信息，或者使用jstack來獲取。

當時的主要發現mysql有較多的locked,因此試着查詢資料及繼續分析，具體資料以下

at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:150)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:114)
at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:161)
at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:189)
- locked <0x00000000a1c98270> (a com.mysql.jdbc.util.ReadAheadInputStream)
at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3036)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3489)
at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3478)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4019)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490)
at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1398)
- locked <0x00000000a1c753c0> (a com.mysql.jdbc.JDBC4Connection)
at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:856)
- locked <0x00000000a1c753c0> (a com.mysql.jdbc.JDBC4Connection)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:2322)
- locked <0x00000000a1c753c0> (a com.mysql.jdbc.JDBC4Connection)

 

四：根據生成的信息，分析CPU使用狀況

查詢資料及分析當時的狀況

分析以下：

1：當時的環境，出現慢SQL的狀況，定位發現，查詢時間過長，發現SQL觸發了性能安全機制，自動加入黑名單中，且數據庫線程被自動殺死

2：經過網上的資料緣由多是操做系統bug。

3：解決方案：上網查詢相關資料，增長數據庫的連接時間，試着增長連接超時時間及stocket時間，進行測試