站長資訊網node服務CPU過高怎么辦？怎么排查？下面本篇文章給大家整理分享下node服務CPU過高的排查思路，希望對大家有所幫助！
node.js極速入門課程：進入學習
幫同事看一個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 去找原因
-
壓測校驗
