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服務CPU過高如何解決就分享到這里了，希望以上內容可以對大家有一定的參考價值，可以學以致用。如果喜歡本篇文章，不妨把它分享出去讓更多的人看到。