一次压测引发的数据库 CPU 飙升_AI阅读总结 — 包阅AI

包阅导读总结

1. 压测、数据库、CPU 飙升、性能指标、行读异常

2. 本文讲述一次压测中数据库 CPU 利用率异常飙升的排查过程。在压测不同流量阶段，CPU 利用率出现异常。经过排查，发现行读异常是主因，由于压测改造方式导致同一账号注册任务增多，使符合条件的行数增加，最终 CPU 花费更多资源处理。

– 压测背景

– 业务需求形成秒杀场景，需对系统和 DB 水位进行压测。

– 压测准备

– 包括流量评估、改造、测试发布、下游流量报备、数据准备、小流量预跑等步骤。

– 压测问题

– 不同流量阶段 CPU 利用率异常。

– 同等流量下压测 CPU 利用率高于线上实际值。

– 流量 80%时 CPU 利用率缓慢上涨，100%时突然飙升。

– 问题排查

– 排除压测改造导致 DB 的 QPS 和 TPS 过高的猜测。

– 发现行读异常，对比定位到有问题的 SQL。

– 明确原因是压测改造方式使同一账号注册任务增多，符合条件的行数增加，CPU 处理资源消耗增加。

– 总结反思

– 压测 80%流量时应关注 CPU 异常。

– 压测时对 DB 性能指标监控不到位。

– 压测改造要注意与场景匹配程度。

思维导图：

文章地址：https://mp.weixin.qq.com/s/n0U3g-R0KmZ97RhH9dzWiw

文章来源：mp.weixin.qq.com

作者：昀鹤

发布时间：2024/6/20 8:02

语言：中文

总字数：2656字

预计阅读时间：11分钟

评分：86分

标签：性能测试,数据库性能,CPU优化,行读优化,SQL效率

以下为原文内容

本内容来源于用户推荐转载，旨在分享知识与观点，如有侵权请联系删除联系邮箱 media@ilingban.com

这是2024年的第43篇文章

（本文阅读时间：15分钟）

一次压测过程中，当数据库的qps和tps都正常时，如果cpu利用率异常的高，应该如何排查？希望通过这篇文章，给你一些启发…

业务需要控制频道内兑换现金的数量，于是在产品设计上给兑换现金增加了库存限制。

在此基础上形成了秒杀场景，峰值时核心接口qps上涨了近600倍（几十到几万），因此需要进行压测来对系统和DB水位摸一下高。

1）压测流量评估：就是定一下每个接口大致压测多少qps，以及压测时到各个下游系统的流量估计。

2）压测改造：因为压测都是用的压测账户，在频道里没有历史痕迹，很多逻辑是走不到的，并且这些逻辑的不同，会直接影响到数据库和下游的流量，因此我们需要根据频道的现有数据进行链路的mock（包括上述的流量评估也得基于这些不同链路的比例去算），举例如下：

3）测试&发布：既然改了代码，还是得交给可爱的测试同学回归下线上链路的，当然压测的链路就可以自己测一测了，看看改造是否符合预期，hsf控制台可以很方便的模拟影子链路：

4）下游流量报备：当然还是得跟各个下游系统知会一声的，切勿悄悄滴进村，打枪滴不要。

5）压测数据准备：主要是压测平台上的各种接口和压测流量配置（注意减去压测时的背景流量），以及压测账号申请等等（这一步也是交给测试同学）。

6）小流量预跑：在正式压测之前，大概用1%的流量先跑一下，看看本身系统以及下游是否有异常（这一步很有必要，有时候下游系统比较复杂，可能部分场景并不能支持压测流量，提前跑一下能发现很多问题，避免正式压测的时候下游报警，然后就是👋忙🦶乱）。

好了，万事具备，经过上面一系列步骤，想必本次压测一定是顺顺利利吧！

====== 10%压测流量，cpu利用率11% ====== 挺正常

====== 30%压测流量，cpu利用率20% ====== 稳中向好

====== 50%压测流量，cpu利用率30% ====== 符合预期

====== 80%压测流量，cpu利用率50% ====== 感觉有点问题，但是说不出来哪里有问题！

====== 100%压测流量，cpu利用率80% ===== 嗯？好像不对劲？有点高

====== 100%压测流量，稳定几分钟后，突然飙到100% ===== …..卧槽，肯定有问题，暂停压测！

看着cpu的监控图，我的脑海里浮现了三个疑问：

1.同等流量下，压测时的cpu利用率为什么高于线上实际值（线上约等于压测80%流量时，cpu利用率实际40%不到，压测时已经到60%了）？

2.流量80%时，为什么压测流量持续不动，cpu利用率会缓慢上涨呢？

3.流量100%时，分明一开始cpu利用率还维持在80%以下，然后突然就飙到100%了？

总体来说，就是CPU高于预期。

第一时间我猜测是我的压测改造不符合预期，导致打到db的qps和tps过高导致。

急了，开始看代码，然后挑了几个压测trace在鹰眼上看调用，没找到问题。

然后发现我好蠢呐（主要是有点慌张），dbservice本身就有tps和qps的监控：

看了一下，有两点，一是持续压测的时候，qps并没有持续上涨，二是差不多同流量下qps的值确实略高于线上实际值，但远远没有cpu差值这么多，所以基本可以排除一开始的猜测。

陷入了瓶颈…..

这时候我知道今天的压测指定是不行了，所以很干脆地摆了，开始安心的找问题～

这时候拉了DBA同学一起帮我们看问题，DBA同学表示，一，数据库在长时间高压下会发生性能劣化，这也是cpu从80%突然暴涨到100%的原因（解答了第三个问题），至于CPU利用率异常是表象，qps和tps只是其中一个影响因素，建议我们看看其他指标。

于是挨个查看数据库性能指标（带宽、慢sql、RT….），然后终于发现了一个疑点：

这个缓慢升高的行读，非常符合压测流量80%时cpu曲线的变化，很可能是问题二的原因…

那是不是也有可能是问题一的原因呢？

对比正常峰值流量下的行读指标

好吧，这都差了一个数量级了，基本可以确定问题出在行读异常上了

开始思考为什么行读这么多还在持续上涨，难道是同一个sql查出来的行数会变多？

其实这时候心里已经隐隐约约猜到问题在哪了，但还是顺着这个行读异常排查下去

通过对比定位到了有问题的sql

压测时：

正常时：

点进去也能看到具体的sql信息：

好吧，和我猜的一样，这下悬着的心终于死了。

至于为什么同一条sql压测的平均行读会高这么多，还是得从代码层面来分析。

首先先看下改造逻辑和逻辑推导：

这么压测改造的原因是压测的账号是有限的（同一批压测账号重复的去轮询），如果所有账号都调过一遍接口，那后面的每次查询都能查到任务，不会再有DB写，为了更好的模拟线上实际情况，因此通过这种方法去让账号重新路由到注册逻辑。

然后看下任务的查询逻辑，如下：

 private TaskInstanceParam createQueryParamByEffectiveTime(TaskQueryParam queryParam) {        final TaskInstanceParam dbQueryParam = new TaskInstanceParam();        Date now = TimeTravelManager.getCurrentTime(queryParam.getUserId());        dbQueryParam.createCriteria()            .andUserIdEqualTo(queryParam.getUserId())            .andBizTypeEqualTo(queryParam.getBizType())            .andTemplateIdEqualTo(queryParam.getSubBizType())            .andEffectiveStartTimeLessThanOrEqualTo(now)            .andEffectiveEndTimeGreaterThan(now);        dbQueryParam.appendOrderByClause(OrderCondition.EFFECTIVESTARTTIME, SortType.DESC);        dbQueryParam.setPagination(1, 1);        return dbQueryParam;    }