本文介绍了在压力测试中遇到MySQL服务CPU占用率过高的问题，通过分析发现业务代码中存在多次不必要的数据库查询。优化SQL语句，减少数据库操作次数，成功降低了CPU占用率并提高了TPS。同时，文章提出一个问题：优化后数据库QPS增加，但CPU占用反而下降，引发思考。
压力测试过程中 MySQL 服务 CPU 占用率过高的问题排查思路
O, 经验总结:
在关注业务接口的 TPS 时, 也要关注数据库服务器的 QPS. 如果一个业务流程里包含多条查询, 那么业务接口 TPS 的上升对数据库服务器 QPS 的放大效应会很明显.
如果查询结果集不大, 尽量使用一条查询语句, 通过子查询返回多个结果集, 避免将多个结果集拆分成多次数据库查询, 否则会造成过多的数据库连接 / 查询操作, 消耗 IO 资源, 降低 TPS, 提高 CPU 占用率.
在业务代码中, 尽量避免在循环语句里写数据库查询.
依据 SQL 语句的使用频率来建立索引, 查询条件字段顺序按照联合索引的字段顺序来写 (从左到右的匹配顺序)
关注慢查日志
一, 背景说明
接着上一篇 Grpc 性能调优的文章继续写, 我们这次压测的是一个查询用户群组列表信息的接口, 该接口里需要查询某个用户的所有群组信息, 包括每个群组的名称, 成员数量等.
经过之前对业务机器的 JVM 参数等进行优化后, 现在已经不存在业务机器的频繁 GC,CPU 占用率过高, TPS 上不去等问题了. 但是我们遇到了两个新问题: 在业务接口并发 50,TPS600 左右时, 压测接口出现了超时错误, 而且数据库服务器 CPU 占用率超过了 93%!
二, 测试过程
数据准备:
t_info_group 群组表:
t_info_group_member 群组成员表:
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
