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

參考連結： https://www.cnblogs.com/zsql/p/11643750.html

2. 看程式碼diff

重啟實例還沒解決，並且確定了是node進程的問題的話，

查看上線commit，檢查一下程式碼diff，看看是否能找到問題點

3. 打運行時的CPU profiler

#這個操作方法和我的另一篇如何快速定位ssr服務端記憶體洩漏問題 類似

• 用node --inspect開始服務

• 本地模擬線上環境，用build後的程式碼，直接build可能會不能用，要控制好環境變量，並且醜化壓縮要關掉

  • 比如，讓一些環境變數（CDN網域等）指向本地，因為打的套件在本地，所以沒上傳到CDN

• 產生CPU profiler

##如果本地無法模擬出線上的環境？

例如下游RPC和本地就是有隔離，那就只能加程式碼，去打出profile了

nodejs.org/docs/latest…

得到profile檔後，用chrome devtool開啟

4. 分析CPU profiler

• #結合profiler 和程式碼diff 去找原因

• #還可以把profile 檔案上傳到

  www.speedscope.app/# （檔案上傳），就能得到cpu profile火焰圖 （更詳細的使用介紹：www.npmjs.com/package/spe…

5. 壓測校驗

可以用ab，或其他壓測工具

總結

• #重啟實例

• 確定是node進程導致的

##看程式碼diff
產生執行階段的CPU profiler
結合profiler 與程式碼diff 去找原因
壓測校驗

#更多node相關知識，請造訪：nodejs 教學！

以上是node服務CPU過高怎麼辦？聊聊排查思路的詳細內容。更多資訊請關注PHP中文網其他相關文章！