今天小編給大家分享的是node服務(wù)CPU過高如何解決，相信很多人都不太了解，為了讓大家更加了解，所以給大家總結(jié)了以下內(nèi)容，一起往下看吧。一定會有所收獲的哦。
創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的郁南網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
幫同事看一個CPU過高的問題
CPU漲了后掉不下去，最終同事排查出來是 某個依賴升級大版本后下線了默認的公共 redis 配置，（項目較老，很久沒人動過）但需要業(yè)務(wù)方代碼里自己配置關(guān)閉 redis服務(wù)。業(yè)務(wù)方有信息gap，所以不知道要關(guān)閉redis，導(dǎo)致上線后，一直在重試連接redis（多一個請求就多一次重試）
最終我們總結(jié)了排查思路，如下，歡迎補充
部分問題，重啟實例就能解決了。
先重啟實例，這是必要做的一步，先讓服務(wù)變得可用。如果后續(xù)CPU還是飆升過快，那么可能只能考慮先回滾代碼了。飆升不快的話，可以不用回滾，盡快排查問題
命令一： top
可以發(fā)現(xiàn)，主要是node進程在占用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
首先看一個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)，當(dāng)這個值超過了CPU數(shù)目，就會出現(xiàn)CPU瓶頸了。這個也和top的負載有關(guān)系，一般負載超過了3就比較高，超過了5就高，超過了10就不正常了，服務(wù)器的狀態(tài)很危險。top的負載類似每秒的運行隊列。如果運行隊列過大，表示你的CPU很繁忙，一般會造成CPU使用率很高。
b #表示阻塞的進程,在等待資源的進程，這個不多說，進程阻塞，大家懂的。
memory
swpd #虛擬內(nèi)存已使用的大小，如果大于0，表示你的機器物理內(nèi)存不足了，如果不是程序內(nèi)存泄露的原因，那么你該升級內(nèi)存了或者把耗內(nèi)存的任務(wù)遷移到其他機器。
free # 空閑的物理內(nèi)存的大小
buff #Linux/Unix系統(tǒng)是用來存儲，目錄里面有什么內(nèi)容，權(quán)限等的緩存
cache #cache直接用來記憶我們打開的文件,給文件做緩沖，把空閑的物理內(nèi)存的一部分拿來做文件和目錄的緩存，是為了提高 程序執(zhí)行的性能，當(dāng)程序使用內(nèi)存時，buffer/cached會很快地被使用。
swap
si #每秒從磁盤讀入虛擬內(nèi)存的大小，如果這個值大于0，表示物理內(nèi)存不夠用或者內(nèi)存泄露了，要查找耗內(nèi)存進程解決掉。我的機器內(nèi)存充裕，一切正常。
so #每秒虛擬內(nèi)存寫入磁盤的大小，如果這個值大于0，同上。
io
bi #塊設(shè)備每秒接收的塊數(shù)量，這里的塊設(shè)備是指系統(tǒng)上所有的磁盤和其他塊設(shè)備，默認塊大小是1024byte
bo #塊設(shè)備每秒發(fā)送的塊數(shù)量，例如我們讀取文件，bo就要大于0。bi和bo一般都要接近0，不然就是IO過于頻繁，需要調(diào)整。
system
in #每秒CPU的中斷次數(shù)，包括時間中斷
cs #每秒上下文切換次數(shù)，例如我們調(diào)用系統(tǒng)函數(shù)，就要進行上下文切換，線程的切換，也要進程上下文切換，這個值要越小越好，太大了，要考慮調(diào)低線程或者進程的數(shù)目
cpu
us #用戶CPU時間，我曾經(jīng)在一個做加密解密很頻繁的服務(wù)器上，可以看到us接近100,r運行隊列達到80(機器在做壓力測試，性能表現(xiàn)不佳)。
sy #系統(tǒng)CPU時間，如果太高，表示系統(tǒng)調(diào)用時間長，例如是IO操作頻繁。
id #空閑 CPU時間，一般來說，id + us + sy = 100,一般我認為id是空閑CPU使用率，us是用戶CPU使用率，sy是系統(tǒng)CPU使用率。
wt #等待IO CPU時間。
實踐
procs r: 運行的進程比較多，系統(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)實內(nèi)核進程所占的百分比，這里us + sy的參考值為80%，如果us+sy 大于 80%說明可能存在CPU不足。
cpu wa: 列顯示了IO等待所占用的CPU時間的百分比。這里wa的參考值為30%，如果wa超過30%，說明IO等待嚴重，這可能是磁盤大量隨機訪問造成的， 也可能磁盤或者磁盤訪問控制器的帶寬瓶頸造成的(主要是塊操作)
參考鏈接： https://www.cnblogs.com/zsql/p/11643750.html
重啟實例還沒解決，并且確定了是node進程的問題的話，
查看上線commit，檢查一下代碼diff，看看是否能找到問題點
這個操作方法和我的另一篇如何快速定位ssr服務(wù)端內(nèi)存泄漏問題 類似
用node --inspect起服務(wù)
本地模擬線上環(huán)境，用build后的代碼，直接build可能會不能用，要控制好環(huán)境變量，并且丑化壓縮要關(guān)掉
比如，讓一些環(huán)境變量（cdn域名等）指向本地，因為打的包在本地，沒上傳到CDN
生成 CPU profiler
比如下游RPC和本地就是有隔離，那就只能加代碼，去打出profile了 nodejs.org/docs/latest…
得到profile文件后，用chrome devtool打開
結(jié)合 profiler 和 代碼diff 去找原因
還可以把 profile 文件 上傳到 www.speedscope.app/ （文件上傳），就能得到cpu profile火焰圖 （更詳細的使用介紹：www.npmjs.com/package/spe…
可以用ab，或其他壓測工具
重啟實例
確定是node進程導(dǎo)致的
看代碼diff
生成運行時的CPU profiler
結(jié)合 profiler 和 代碼diff 去找原因
壓測校驗
關(guān)于node服務(wù)CPU過高如何解決就分享到這里了，希望以上內(nèi)容可以對大家有一定的參考價值，可以學(xué)以致用。如果喜歡本篇文章，不妨把它分享出去讓更多的人看到。
重慶分公司
重慶分公司
