node服務(wù)CPU過高怎么辦？怎么排查？下面本篇文章給大家整理分享下node服務(wù)CPU過高的排查思路，希望對大家有所幫助！

node.js極速入門課程：進(jìn)入學(xué)習(xí)

幫同事看一個(gè)CPU過高的問題

• CPU漲了后掉不下去，最終同事排查出來是 某個(gè)依賴升級大版本后下線了默認(rèn)的公共 redis 配置，（項(xiàng)目較老，很久沒人動(dòng)過）但需要業(yè)務(wù)方代碼里自己配置關(guān)閉 redis服務(wù)。業(yè)務(wù)方有信息gap，所以不知道要關(guān)閉redis，導(dǎo)致上線后，一直在重試連接redis（多一個(gè)請求就多一次重試）

最終我們總結(jié)了排查思路，如下，歡迎補(bǔ)充

排查思路

0. 重啟實(shí)例

部分問題，重啟實(shí)例就能解決了。

先重啟實(shí)例，這是必要做的一步，先讓服務(wù)變得可用。如果后續(xù)CPU還是飆升過快，那么可能只能考慮先回滾代碼了。飆升不快的話，可以不用回滾，盡快排查問題

1. linux shell 確定是否是node進(jìn)程造成的

命令一： top

• 可以發(fā)現(xiàn)，主要是node進(jìn)程在占用CPU?！鞠嚓P(guān)教程推薦：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

• 首先看一個(gè)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 #表示運(yùn)行隊(duì)列(就是說多少個(gè)進(jìn)程真的分配到CPU)，當(dāng)這個(gè)值超過了CPU數(shù)目，就會(huì)出現(xiàn)CPU瓶頸了。這個(gè)也和top的負(fù)載有關(guān)系，一般負(fù)載超過了3就比較高，超過了5就高，超過了10就不正常了，服務(wù)器的狀態(tài)很危險(xiǎn)。top的負(fù)載類似每秒的運(yùn)行隊(duì)列。如果運(yùn)行隊(duì)列過大，表示你的CPU很繁忙，一般會(huì)造成CPU使用率很高。

  b #表示阻塞的進(jìn)程,在等待資源的進(jìn)程，這個(gè)不多說，進(jìn)程阻塞，大家懂的。

• memory

  swpd #虛擬內(nèi)存已使用的大小，如果大于0，表示你的機(jī)器物理內(nèi)存不足了，如果不是程序內(nèi)存泄露的原因，那么你該升級內(nèi)存了或者把耗內(nèi)存的任務(wù)遷移到其他機(jī)器。

  free # 空閑的物理內(nèi)存的大小

  buff #Linux/Unix系統(tǒng)是用來存儲(chǔ)，目錄里面有什么內(nèi)容，權(quán)限等的緩存

  cache #cache直接用來記憶我們打開的文件,給文件做緩沖，把空閑的物理內(nèi)存的一部分拿來做文件和目錄的緩存，是為了提高 程序執(zhí)行的性能，當(dāng)程序使用內(nèi)存時(shí)，buffer/cached會(huì)很快地被使用。

• swap

  si #每秒從磁盤讀入虛擬內(nèi)存的大小，如果這個(gè)值大于0，表示物理內(nèi)存不夠用或者內(nèi)存泄露了，要查找耗內(nèi)存進(jìn)程解決掉。我的機(jī)器內(nèi)存充裕，一切正常。

  so #每秒虛擬內(nèi)存寫入磁盤的大小，如果這個(gè)值大于0，同上。

• io

  bi #塊設(shè)備每秒接收的塊數(shù)量，這里的塊設(shè)備是指系統(tǒng)上所有的磁盤和其他塊設(shè)備，默認(rèn)塊大小是1024byte

  bo #塊設(shè)備每秒發(fā)送的塊數(shù)量，例如我們讀取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO過于頻繁，需要調(diào)整。

• system

  in #每秒CPU的中斷次數(shù)，包括時(shí)間中斷

  cs #每秒上下文切換次數(shù)，例如我們調(diào)用系統(tǒng)函數(shù)，就要進(jìn)行上下文切換，線程的切換，也要進(jìn)程上下文切換，這個(gè)值要越小越好，太大了，要考慮調(diào)低線程或者進(jìn)程的數(shù)目

• cpu

  us #用戶CPU時(shí)間，我曾經(jīng)在一個(gè)做加密解密很頻繁的服務(wù)器上，可以看到us接近100,r運(yùn)行隊(duì)列達(dá)到80(機(jī)器在做壓力測試，性能表現(xiàn)不佳)。

  sy #系統(tǒng)CPU時(shí)間，如果太高，表示系統(tǒng)調(diào)用時(shí)間長，例如是IO操作頻繁。

  id #空閑 CPU時(shí)間，一般來說，id + us + sy = 100,一般我認(rèn)為id是空閑CPU使用率，us是用戶CPU使用率，sy是系統(tǒng)CPU使用率。

  wt #等待IO CPU時(shí)間。

• 實(shí)踐

  procs r: 運(yùn)行的進(jìn)程比較多，系統(tǒng)很繁忙
  bi/bo: 磁盤寫的數(shù)據(jù)量稍大，如果是大文件的寫，10M以內(nèi)基本不用擔(dān)心，如果是小文件寫2M以內(nèi)基本正常
  cpu us: 持續(xù)大于50%，服務(wù)高峰期可以接受， 如果長期大于50 ，可以考慮優(yōu)化
  cpu sy: 現(xiàn)實(shí)內(nèi)核進(jìn)程所占的百分比，這里us + sy的參考值為80%，如果us+sy 大于 80%說明可能存在CPU不足。
  cpu wa: 列顯示了IO等待所占用的CPU時(shí)間的百分比。這里wa的參考值為30%，如果wa超過30%，說明IO等待嚴(yán)重，這可能是磁盤大量隨機(jī)訪問造成的， 也可能磁盤或者磁盤訪問控制器的帶寬瓶頸造成的(主要是塊操作)

參考鏈接： https://www.cnblogs.com/zsql/p/11643750.html

2. 看代碼diff

重啟實(shí)例還沒解決，并且確定了是node進(jìn)程的問題的話，

查看上線commit，檢查一下代碼diff，看看是否能找到問題點(diǎn)

3. 打運(yùn)行時(shí)的CPU profiler

這個(gè)操作方法和我的另一篇如何快速定位ssr服務(wù)端內(nèi)存泄漏問題 類似

• 用node –inspect起服務(wù)

• 本地模擬線上環(huán)境，用build后的代碼，直接build可能會(huì)不能用，要控制好環(huán)境變量，并且丑化壓縮要關(guān)掉

  • 比如，讓一些環(huán)境變量（CDN域名等）指向本地，因?yàn)榇虻陌诒镜?，沒上傳到CDN

• 生成 CPU profiler

如果本地?zé)o法模擬出線上的環(huán)境？

比如下游RPC和本地就是有隔離，那就只能加代碼，去打出profile了 nodejs.org/docs/latest…

得到profile文件后，用chrome devtool打開

4. 分析 CPU profiler

• 結(jié)合 profiler 和 代碼diff 去找原因

• 還可以把 profile 文件 上傳到 www.speedscope.app/ （文件上傳），就能得到cpu profile火焰圖 （更詳細(xì)的使用介紹：www.npmjs.com/package/spe…

5. 壓測校驗(yàn)

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

總結(jié)

• 重啟實(shí)例

• 確定是node進(jìn)程導(dǎo)致的

• 看代碼diff

• 生成運(yùn)行時(shí)的CPU profiler

• 結(jié)合 profiler 和 代碼diff 去找原因

• 壓測校驗(yàn)