新手区 性能测试实战案例 (问题定位和优化方法)

大话性能 · 2018年11月05日 · 最后由 大话性能 回复于 2018年11月05日 · 2907 次阅读

做性能测试做多了,你会发现服务器最慢的是 io,而数据库是经常和 io 打交道的,所以是最容易出现瓶颈和问题的就是数据库服务器,一不小心就会崩掉。在这里分享一个在实际性能项目中成功解决 cpu 高负荷问题。


更多测试技能干货,可以关注微信公众号<大话性能>

更多好文章

1、问题描述

某项目是在做性能测试的过程中,发现某个计数查询接口小并发的压测后,mysql 数据库服务器的 CPU(4 核)就满负荷运行,而接口的 tps 也是很小。

2、问题解决

根据经验,数据库的 cpu 满负荷运行,大部分情况下是索引没建好。

问题定位和解决步骤:

1、登陆 mysql 的服务器后,执行 mysql -uroot -proot -h192.168.16.59 -P33061 -e 'show full processlist;' | grep -v 'Sleep' ,观察有无执行缓慢或者经常出现的 sql 语句,发现不断出现 select count(*) from t_member_dayranklist WHERE ( update_date = '2015-11-02 00:00:00' and department_id = 22292800 );类似语句。

2、于是 explain 它们,观察 MySQL 是如何处理该 SQL 语句的,索引是如何被利用的,数据表是如何被搜索和排序的。

3、Show index from t_member_dayranklist 后发现建立的表索引只有列 update_date, department_id 的单独索引,而 explain 查询语句结果如下,发现需要搜索的 rows 也有 5506 行,并且显示索引被使用的 ref 值为 null,可见索引有优化的空间。

4、于是尝试 alter table t_member_dayranklist add index date_dept_idx (update_date , department_id);增加一个组合索引。

5、修改后发现索引的效率确实高了一些,而此时索引也确实是按照我添加的 date_dept_idx 进行搜索,搜索的行数也比之前的少了 2/3。

3、结果对比

优化后的效果出乎我的想象,第一次切身感受到了正确的索引带来的性能提升还是很客观的,具体结果如下:


从上图,可以清晰的看出 Mysql 数据库服务器的 CPU 平均使用率下降了接近了 55%,接口的平均响应时间从 1023ms 下降到 113ms,而 TPS 处理能力从 97.5/s 上升到 873.0/s,很好的满足了系统和接口的需求。

在实际 mysql 数据库性能调优中,十有八九的问题都可以从索引出发,不仅仅要建立相应的索引,还要建立合理的索引,最后还要测试索引是否生效。
更多性能测试相关学习可以关注公众号大话性能。更多好文章

共收到 5 条回复 时间 点赞

经验分享

赞,写的很不错!

JKzhishui 回复

谢谢,😄

不错不错~~~

魏海峰 回复

😄

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册