<listing id="z3xzv"><menuitem id="z3xzv"><meter id="z3xzv"></meter></menuitem></listing>
<address id="z3xzv"></address>
<noframes id="z3xzv"><address id="z3xzv"><listing id="z3xzv"></listing></address>

    <address id="z3xzv"><address id="z3xzv"><listing id="z3xzv"></listing></address></address><form id="z3xzv"><listing id="z3xzv"><meter id="z3xzv"></meter></listing></form><form id="z3xzv"></form><form id="z3xzv"><listing id="z3xzv"><meter id="z3xzv"></meter></listing></form>
    <noframes id="z3xzv">

    <form id="z3xzv"></form>
    溫馨提示×

    node服務CPU過高如何解決

    發布時間:2022-09-16 13:54:06 來源:億速云 閱讀:54 作者:栢白 欄目:web開發

    今天小編給大家分享的是node服務CPU過高如何解決,相信很多人都不太了解,為了讓大家更加了解,所以給大家總結了以下內容,一起往下看吧。一定會有所收獲的哦。

    幫同事看一個CPU過高的問題

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

    最終我們總結了排查思路,如下,歡迎補充

    排查思路

    0. 重啟實例

    部分問題,重啟實例就能解決了。

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

    1. linux shell 確定是否是node進程造成的

    命令一: top

    • 可以發現,主要是node進程在占用CPU?!鞠嚓P教程推薦: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

    node服務CPU過高如何解決

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

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

    node服務CPU過高如何解決

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

    node服務CPU過高如何解決

    4. 分析 CPU profiler

    • 結合 profiler 和 代碼diff 去找原因

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

    node服務CPU過高如何解決

    5. 壓測校驗

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

    總結

    • 重啟實例

    • 確定是node進程導致的

    • 看代碼diff

    • 生成運行時的CPU profiler

    • 結合 profiler 和 代碼diff 去找原因

    • 壓測校驗

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

    推薦閱讀:tomcat占用cpu過高解決辦法

    免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。

    主題地圖

    日本亚洲一区二区
    <listing id="z3xzv"><menuitem id="z3xzv"><meter id="z3xzv"></meter></menuitem></listing>
    <address id="z3xzv"></address>
    <noframes id="z3xzv"><address id="z3xzv"><listing id="z3xzv"></listing></address>

      <address id="z3xzv"><address id="z3xzv"><listing id="z3xzv"></listing></address></address><form id="z3xzv"><listing id="z3xzv"><meter id="z3xzv"></meter></listing></form><form id="z3xzv"></form><form id="z3xzv"><listing id="z3xzv"><meter id="z3xzv"></meter></listing></form>
      <noframes id="z3xzv">

      <form id="z3xzv"></form>