在一次性能测试中，当并发数升至400时，程序的TPS骤降，数据库CPU使用率达到90%。问题定位到一个定时任务触发的全表扫描操作，尽管涉及数据量仅10w条，但在高并发下，全表扫描导致资源消耗严重。通过监控数据库进程和SQL执行计划，确认这一操作是性能瓶颈所在。后续进行了优化，以降低并发查询时的资源占用。
记一次年前，性能测试组人员，给我测试出的bug吧，说实话，这种bug也只有在高并发情况下才会出现。
说下业务背景，我的程序中有一段逻辑是这样设计的：用户第一次请求，我会根据用户的请求条件，用哈希算法算出一个 哈希值，再将用户的请求条件插入的到一张表里；然后拿查询条件去请求其他系统（耗时较长）和查询本地数据库里的业务表（数据量较大），这样查询完后，会将两部分的数据汇总到一张结果表里，然后再从结果表中将数据统一查出返回给调用系统。
原本这也没啥问题，测试几轮下来，除了数据质量问题（与程序无关），没有出现过其他状况。直到性能测试，给我搞的很难受。
性能测试很重要得一个指标就是 tps，还有在并发情况下，服务器各项指标是否正常。
测试人员在将并发数调整到400后，持续1小时压测，进行到5分钟时，突然 tps断崖式下降至200，再5分钟100。同时数据库 cpu TOP命令下，cpu达到90。相当不正常，不正常了，就需要去排查。
排查主要集中在两点：1.测试哪个接口 2.为什么5分钟tps规律性的下降。
程序中5分钟有一个定时任务会进行清理操作，这部分操作会对查询的表进行 update、delete操作，但是我分析这张表总的数据量也就10w条左右，可能并不会影响；然后事实跟我想的正好相反，恰好就是这张不起眼的表导致的数据库cpu被沾满。紧接着说下排查过程、优化过程。
使用top命令时，可以看到有个进程占用率特别高 复制它的进程 id
process
然后进入到到数据库中 执行语句 select * from v$process where spid=进程号
select * from v$session where paddr=“地址”
select* from v$sql where sql_id=‘上面查出的sqlid’；
即可找到对应消耗cpu较多的sql语句。结果就是我刚才说的只有10w左右数据量的sql。
单纯执行这个sql并不会耗费多少资源，但是一旦并发查询的话，就很多了，因为我看他执行计划时全表扫描，这种即使10w条数据，高并发情况下，耗费资源依然很严重，一定要注意。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
