引言
背景: 在某一天,运营同事突然发现运营看板好几天没有更新数据了, 然后找了过来?!
这里看似抛出了一个问题 ?
但细想一下, 同时暴露了我们对于线上服务的监控未完全覆盖到!!! 这是致命的!!!
当然, 这篇文章先不讨论监控的问题, 后面会推出完善的监控方案
定位问题
问题抛过来了, 那么我们第一步要怎样做呢?
拿到问题的第一步, 先理解题意, 这里有几个关键的信息点
第一 : 好几天, 具体哪一天, 这个后面确认了一个具体的时间点
第二 : 运营看板, 这是重点, 是我们切入问题的关键
好了, 有了这两个关键的信息, 我们接下来就开始定位问题代码了
- 从功能出发, 定位到未更新的表
- 通过表来定位到更新数据的代码
通过上面两步找到了问题代码是某个定时任务
日志搜索
这时按照肌肉记忆, 先是看了代码有没有关键点的日志输出, 发现代码开始和结束都有打印日志的操作
顺藤摸瓜,先登录到服务器端, grep一波关键的日志
发现当天的 info.log 没有打印到日志, 这就很奇怪了, 因为这个定时任务的 cron 是每天凌晨1点开始
然后就查了前一天的日志, 发现有打印到开始的日志, 但是没有打印结束的日志
然后再去找看有没有异常的日志, 发现并没有
监控看板
从日志看出了一点不对劲的味道, 但还没有足够的线索定位到具体的问题
这时去查看容器的资源情况
这里观察的是, 在两台容器中, 有一台容器的 cpu 吃得很紧
另外一台却是风平浪静
从这里可以定位到大概的问题了: CPU负载高
那为什么会造成 CPU 跑那么高呢 ?
ThreadDump
当然有很多方案可以定位 CPU 的瓶颈问题,像使用火焰图定位(下一篇会使用到)
但从上面的蛛丝马迹里可以大体定位到是具体的定时任务引起的
这时 threaddump, 并分析了一波线程的运行情况
从整体的报告可以看出有阻塞的线程两个, 同时有百分之四十是在超时等待
再看看具体被阻塞的线程
看起来是数据库查询阻塞
看具体的业务代码
分析一下这条 SQL 的变量
入参只有一个就是 classIds 数组:
- 数量很小
- 数量很大
- 数量为 0
数组的分布情况可以为上面几种
套进去
- 数量很小, 查询应该很快
- 数量很大, 查询应该会相对慢一点
- 数量为 0 呢, if 标签, classIds 数量为 0, 不会 拼接下面的 sql, 也就是会查全表
优化
定位到具体的代码了, 那就是要出优化方案了
做法就是当 classIds 的大小为 0 的时候, 不要扫描全表
这里添加 otherwise 分支, classIds 大小为 0 是 and false
重新部署再观察线上情况, CPU 降了下来
事后反思
为什么会这么久才发现问题? 而且依赖于业务侧发现问题
能不能提前感知问题呢?
想了一下, 我们的监控更多是在监测代码抛出异常, 对于操作系统的资源缺少监控 下一步的优化, 对操作系统资源进行监控
以上就是线上Spring CPU 高负载解决思路详解的详细内容，更多关于线上Spring CPU 高负载的资料请关注Devmax其它相关文章！