记一次CPU持续增长的问题解决

背景

线上服务在一次功能变更上线的约一周后, 出现了服务超时问题

直观考虑

Q1: 由于服务本身定位是下游的保障服务, 服务质量受上游流量影响, 对上流的突发大流量请求, 偶尔会有超时情况出现;

A1: 查看上游请求流量, 发现在时间上吻合, 确实存在突增的上游流量, 查看此时流量已经下降, 继续观察超时发生情况;

约几分钟后, 发现超时请求量下降, 但仍然存在。和前几天同时段相比, 有所升高, 先重启服务, 后续定位。

后续定位

考虑到最新的服务变更, 以及上线后约一周才出现的问题。

所以在服务重启后, 持续观察服务的指标情况, 发现服务实例的网络包传输量和cpu占用逐步增长, 网络包传输情况如下:

​根据cpu和网络包的同时增长, 基本可以断定是后台有定时任务不断发送网络请求导致。

考虑到本次功能主要变更为:

使用「触发式缓存刷新」代替「定时的缓存刷新」功能

怀疑大概率与此功能的部分实现有问题有关。

这里使用的简单的redis的pub/sub机制, 可能启动了越来越多的listener, 导致一直刷新, 查看对应代码, 也是做了类似的全局唯一处理。

代码片段如下:

​既然不是, 剩下的就是复杂的业务模块, 一个一个排查不现实, 上工具。

查看cpu时间, py-spy火焰图正合适, 在预上线准备环境, 得到火焰图如下: