node服務CPU過高怎麼辦？聊聊排查思路-js教程-PHP中文網

node服務CPU過高怎麼辦？怎麼排查？以下這篇文章給大家整理分享下node服務CPU過高的檢驗思路，希望對大家有幫助！

node服務CPU過高怎麼辦？聊聊排查思路

幫同事看一個CPU過高的問題

CPU漲了後掉不下去，最後同事排查出來是某個依賴升級大版本後下線了預設的公共redis 配置，（專案較老，很久沒人動過）但需要業務方代碼裡自己配置關閉redis服務。業務方有資訊gap，所以不知道要關閉redis，導致上線後，一直在重試連接redis（多一個請求就多一次重試）

最終我們總結了排查思路，如下，歡迎補充

排查思路

0. 重啟實例

部分問題，重啟實例就能解決了。

先重啟實例，這是必要做的一步，先讓服務變得可用。如果後續CPU還是飆升過快，那麼可能只能考慮先回滾程式碼了。飆升不快的話，可以不用回滾，盡快排查問題

1. linux shell 確定是否是node進程造成的

命令一：top

可以發現，主要是node進程在佔用CPU。【相關教學推薦：nodejs影片教學】

[root@*** ~]# top PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 680 root 20 0 2290976 168176 34976 S 30.3 2.0 103:42.59 node 687 root 20 0 2290544 166920 34984 R 26.3 2.0 96:26.42 node 52 root 20 0 1057412 23972 15188 S 1.7 0.3 11:25.97 **** 185 root 20 0 130216 41432 25436 S 0.3 0.5 1:03.44 **** ...

登入後複製

指令二：vmstat

先看一個vmstat 2 指令，表示每隔兩秒鐘採集一次

[root@*** ~]# vmstat 2 procs -----------memory---------------- ---swap-- -----io---- --system-- -----cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 233481328 758304 20795516 0 0 0 1 0 0 0 0 100 0 0 0 0 0 233480800 758304 20795520 0 0 0 0 951 1519 0 0 100 0 0 0 0 0 233481056 758304 20795520 0 0 0 0 867 1460 0 0 100 0 0 0 0 0 233481408 758304 20795520 0 0 0 20 910 1520 0 0 100 0 0 0 0 0 233481680 758304 20795520 0 0 0 0 911 1491 0 0 100 0 0 0 0 0 233481920 758304 20795520 0 0 0 0 889 1530 0 0 100 0 0

登入後複製

procs
#r #表示執行佇列(就是說多少個行程真的被分配到CPU)，當這個數值超過了CPU數目，就會出現CPU瓶頸了。這個也跟top的負載有關係，一般負載超過了3就比較高，超過了5就高，超過了10就不正常了，伺服器的狀態很危險。 top的負載類似每秒的運行佇列。如果運行佇列過大，表示你的CPU很繁忙，一般會造成CPU使用率很高。
b #表示阻塞的進程,在等待資源的進程，這個不多說，進程阻塞，大家懂的。
memory
swpd #虛擬記憶體已使用的大小，如果大於0，表示你的機器物理記憶體不足了，如果不是程式記憶體外洩的原因，那麼你該升級記憶體了或是把耗記憶體的任務移轉到其他機器。
free # 空閒的實體記憶體的大小
buff #Linux/Unix系統是用來存儲，目錄裡面有什麼內容，權限等的快取
cache #cache直接用來記憶我們打開的文件,給文件做緩衝，把空閒的物理內存的一部分拿來做文件和目錄的緩存，是為了提高程序執行的性能，當程序使用內存時，buffer/cached會很快地被使用。
swap
si #每秒從磁碟讀入虛擬記憶體的大小，如果這個值大於0，表示物理記憶體不夠用或記憶體洩露了，要查找耗內存進程解決掉。我的機器記憶體充裕，一切正常。
so #每秒虛擬記憶體寫入磁碟的大小，如果這個值大於0，同上。
io
bi #區塊設備每秒接收的區塊數量，這裡的區塊裝置是指系統上所有的磁碟和其他區塊設備，預設區塊大小是1024byte
bo #區塊裝置每秒鐘發送的區塊數量，例如我們讀取文件，bo就要大於0。 bi和bo一般都要接近0，不然就是IO太頻繁，需要調整。
system
in #每秒CPU的中斷次數，包含時間中斷
cs #每秒情境切換次數，例如我們呼叫系統函數，就要進行上下文切換，線程的切換，也要進程上下文切換，這個值要越小越好，太大了，要考慮調低線程或者進程的數目
cpu
us #用戶CPU時間，我曾經在一個做加密解密很頻繁的伺服器上，可以看到us接近100,r運行隊列達到80(機器在做壓力測試，性能表現不佳) 。
sy #系統CPU時間，如果太高，表示系統呼叫時間長，例如IO操作頻繁。
id #空閒 CPU時間，一般來說，id us sy = 100,一般我認為id是空閒CPU使用率，us是使用者CPU使用率，sy是系統CPU使用率。
wt #等待IO CPU時間。
實踐
#
procs r: 運作的進程比較多，系統很忙
bi/bo: 磁碟寫的資料量稍大，如果是大檔案的寫，10M以內基本上不用擔心，如果是小檔案寫2M以內基本正常
cpu us: 持續大於50%，服務高峰期可以接受，如果長期大於50 ，可以考慮優化
cpu sy: 現實內核進程所佔的百分比，這裡us sy的參考值為80% ，如果us sy 大於80%說明可能有CPU不足。
cpu wa: 列顯示了IO等待所佔用的CPU時間的百分比。這裡wa的參考值為30%，如果wa超過30%，表示IO等待嚴重，這可能是磁碟大量隨機存取造成的，也可能磁碟或磁碟存取控制器的頻寬瓶頸造成的(主要是區塊操作)