node服务CPU过高怎么办?聊聊排查思路

node服务CPU过高怎么办?怎么排查?下面本篇文章给大家整理分享下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

1.png

如果本地无法模拟出线上的环境?

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

2.png

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

3.png

4. 分析 CPU profiler

  • 结合 profiler 和 代码diff 去找原因

  • 还可以把 profile 文件 上传到 www.speedscope.app/ (文件上传),就能得到cpu profile火焰图 (更详细的使用介绍:www.npmjs.com/package/spe…

4.png

5. 压测校验

可以用ab,或其他压测工具

总结

  • 重启实例

  • 确定是node进程导致的

  • 看代码diff

  • 生成运行时的CPU profiler

  • 结合 profiler 和 代码diff 去找原因

  • 压测校验

更多node相关知识,请访问:nodejs 教程!

以上就是node服务CPU过高怎么办?聊聊排查思路的详细内容,更多请关注https://www.sxiaw.com/其它相关文章!