V2EX = way to explore V2EX 是一个关于分享和探索的地方
Sign Up Now For Existing Member Sign In
请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 2347 days ago, the information mentioned may be changed or developed.
先说现象，服务器每隔一小时 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 飙升，有没有哪路神仙遇到此问题，或能提供定位问题思路。
服务器环境（阿里云的 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 飙升，有没有哪路神仙遇到此问题，或能提供定位问题思路。
Supplement 1 Jun 16, 2020
最后自己找到问题了。
这里涉及到两个问题，都和定时器相关。
第一个是 swoole 的定时释放内存，原来的频率很高，1 秒钟一次，经过反馈后改成了 60 秒。
另外一个是在 swoole 上自行实现的定时任务逻辑问题，存在潜在重叠。
这是国外一个分析文章： https://blog.avast.com/investigation-of-regular-high-load-on-unused-machines-every-7-hours
这里涉及到两个问题，都和定时器相关。
第一个是 swoole 的定时释放内存，原来的频率很高，1 秒钟一次，经过反馈后改成了 60 秒。
另外一个是在 swoole 上自行实现的定时任务逻辑问题，存在潜在重叠。
这是国外一个分析文章： https://blog.avast.com/investigation-of-regular-high-load-on-unused-machines-every-7-hours
 | 1 OP 补充： 1.只要连接数上来就会出现，所以问题和长连接数量相关 2.心跳是 60 秒一次，回应 pong 即可，处理效率不存在瓶颈 |
 | 2 jybox Nov 25, 2019 监控采集的粒度不够？有可能只是极短时间的 CPU 繁忙导致的 load 升高。 |
 | 3 asilin Nov 25, 2019 我猜测是短时间内大量进程 /线程的创建导致的，推荐使用 ganglia 或者 prometheus 监控来看下； |
 | 6 Sasasu Nov 25, 2019 gc 扫描 |
 | 8 dazhangpan Nov 25, 2019 同意#3 楼，不要光看代码，还是得用工具看一下是否有 short-lived 进程，可以参考这篇文章： https://decodezp.github.io/2019/09/19/test20-troubleshoot-short-lived-process/ |
| 9 z5864703 OP @dazhangpan 看了下，不符合条件。服务器在负载飙升的时候是没有 cpu 占用开销 |
 | 10 capljf Nov 26, 2019 如果确定是业务代码造成的 load 飙升并且是运行 jvm 的话，可以在 load 升起来的时候 dump 一下内存看看 |
Select Language