这是一个创建于 2223 天前的主题，其中的信息可能已经有所发展或是发生改变。
先说现象，服务器每隔一小时 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 飙升，有没有哪路神仙遇到此问题，或能提供定位问题思路。
第 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
这里涉及到两个问题，都和定时器相关。
第一个是 swoole 的定时释放内存，原来的频率很高，1 秒钟一次，经过反馈后改成了 60 秒。
另外一个是在 swoole 上自行实现的定时任务逻辑问题，存在潜在重叠。
这是国外一个分析文章： https://blog.avast.com/investigation-of-regular-high-load-on-unused-machines-every-7-hours
 | 1 z5864703 OP 补充： 1.只要连接数上来就会出现，所以问题和长连接数量相关 2.心跳是 60 秒一次，回应 pong 即可，处理效率不存在瓶颈 |
 | 2 jybox 2019-11-25 17:38:50 +08:00 监控采集的粒度不够？有可能只是极短时间的 CPU 繁忙导致的 load 升高。 |
 | 3 asilin 2019-11-25 17:43:23 +08:00 我猜测是短时间内大量进程 /线程的创建导致的，推荐使用 ganglia 或者 prometheus 监控来看下； |
| 4 z5864703 OP @jybox 每秒记录，load 的数值飙升到回落持续时间两分钟，飙升过程 40 秒左右。cpu 没有波动，包括每个核心 |
 | 6 Sasasu 2019-11-25 19:19:16 +08:00 gc 扫描 |
 | 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/ |
| 9 z5864703 OP @dazhangpan 看了下，不符合条件。服务器在负载飙升的时候是没有 cpu 占用开销 |
 | 10 capljf 2019-11-26 13:43:07 +08:00 如果确定是业务代码造成的 load 飙升并且是运行 jvm 的话，可以在 load 升起来的时候 dump 一下内存看看 |
Select Language