V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
z5864703
V2EX  ›  程序员

关于 load average 一个诡异的问题

  •  
  •   z5864703 ·
    z5864703 · 2019-11-25 17:33:15 +08:00 · 2220 次点击
    这是一个创建于 1860 天前的主题,其中的信息可能已经有所发展或是发生改变。
    先说现象,服务器每隔一小时 22 分 load 负载就会从平均 0.6 飙升到 5-7 之间,持续两分钟就回落正常水平,并且偶尔会有三四个小时不出现。诡异的地方是没找到能体现负载上升的关联数据指标,就是检查了所知道的数据都是正常的没有波动,除了 load 负载。
    服务器环境(阿里云的 ECS,C6 型):
    系统:centos 7.6.1810
    CPU:8 核 intel 的 8269CY
    内存:16G,没有开 swap
    磁盘:高效云盘 40G
    网卡:1 张自带+2 张弹性网卡(公网 IP )
    程序:php7.2.24+swoole4.4.12
    业务:差不多维持四十万左右的 TCP 长连接,平常主要数据交互就是心跳指令数据收发

    负载飙升的时候,检查监控记录过以下数据指标,并和正常情况下的指标对比,并无异常。
    cpu 占用率:10%左右波动
    内存占用:7G 左右平稳( 16G 的总内存)
    磁盘 IO:几乎没有,因为业务是数据转发性质,纯内存
    处于 R 状态进程:1-5 之间波动
    处于 D 状态进程:没有
    系统中断:四万七左右波动(通过 vmstat -Sm 1 查看)
    上下文切换:五万左右波动(通过 vmstat -Sm 1 查看)
    系统函数调用:排名前三 kernel 的_raw_spin_unlock_irqrestore、__do_softirq 与 php 的 execute_ex 保持不变(通过 perf top 查看)
    网络流量:维持出 4Mbps 左右,入 7Mbps 左右
    网络连接数:无波动

    目前可以肯定和业务程序相关,只要业务程序关闭,就不会出现这个现象。但是检查过业务代码,没有符合特征的代码,比如定时器。
    目前就是要找到会是什么原因导致的 load 飙升,有没有哪路神仙遇到此问题,或能提供定位问题思路。
    第 1 条附言  ·  2020-06-16 16:12:32 +08:00
    最后自己找到问题了。
    这里涉及到两个问题,都和定时器相关。
    第一个是 swoole 的定时释放内存,原来的频率很高,1 秒钟一次,经过反馈后改成了 60 秒。
    另外一个是在 swoole 上自行实现的定时任务逻辑问题,存在潜在重叠。
    这是国外一个分析文章: https://blog.avast.com/investigation-of-regular-high-load-on-unused-machines-every-7-hours
    11 条回复    2019-11-26 14:58:33 +08:00
    z5864703
        1
    z5864703  
    OP
       2019-11-25 17:36:25 +08:00
    补充:
    1.只要连接数上来就会出现,所以问题和长连接数量相关
    2.心跳是 60 秒一次,回应 pong 即可,处理效率不存在瓶颈
    jybox
        2
    jybox  
       2019-11-25 17:38:50 +08:00
    监控采集的粒度不够?有可能只是极短时间的 CPU 繁忙导致的 load 升高。
    asilin
        3
    asilin  
       2019-11-25 17:43:23 +08:00
    我猜测是短时间内大量进程 /线程的创建导致的,推荐使用 ganglia 或者 prometheus 监控来看下;
    z5864703
        4
    z5864703  
    OP
       2019-11-25 18:00:51 +08:00
    @jybox 每秒记录,load 的数值飙升到回落持续时间两分钟,飙升过程 40 秒左右。cpu 没有波动,包括每个核心
    z5864703
        5
    z5864703  
    OP
       2019-11-25 18:04:15 +08:00
    @asilin 业务在启动完就创建完相关进程和线程,运行过程中不会有这个操作
    Sasasu
        6
    Sasasu  
       2019-11-25 19:19:16 +08:00
    gc 扫描
    z5864703
        7
    z5864703  
    OP
       2019-11-25 19:59:29 +08:00
    @Sasasu php 的 gc ?还是?
    dazhangpan
        8
    dazhangpan  
       2019-11-25 20:04:23 +08:00
    同意#3 楼,不要光看代码,还是得用工具看一下是否有 short-lived 进程,可以参考这篇文章: https://decodezp.github.io/2019/09/19/test20-troubleshoot-short-lived-process/
    z5864703
        9
    z5864703  
    OP
       2019-11-25 20:19:53 +08:00
    @dazhangpan 看了下,不符合条件。服务器在负载飙升的时候是没有 cpu 占用开销
    capljf
        10
    capljf  
       2019-11-26 13:43:07 +08:00
    如果确定是业务代码造成的 load 飙升并且是运行 jvm 的话,可以在 load 升起来的时候 dump 一下内存看看
    z5864703
        11
    z5864703  
    OP
       2019-11-26 14:58:33 +08:00
    @capljf 不是 jvm,是 php 环境
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2456 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 15:48 · PVG 23:48 · LAX 07:48 · JFK 10:48
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.