首頁 >web前端 >js教程 >node服務CPU過高怎麼辦？聊聊排查思路

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

青灯夜游轉載: 2022-09-15 19:46:253842瀏覽

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等待嚴重，這可能是磁碟大量隨機存取造成的，也可能磁碟或磁碟存取控制器的頻寬瓶頸造成的(主要是區塊操作)