nmon问题定位和LoadRunner结果分析

原创

cnhkzyy 2022-07-04 20:17:43 博主文章分类：性能 ©著作权

文章标签 mysql 响应时间慢查询 文章分类 MySQL 数据库

©著作权归作者所有：来自51CTO博客作者cnhkzyy的原创作品，请联系作者获取转载授权，否则将追究法律责任

一. 场景设计回顾

1. 在我们实际工作中，一般是先做单场景（单接口）的性能测试，当没有问题后，或者优化之后，再做混合场景，这是基于以下两点考虑

(1) 为了更好的排查问题，更好的优化问题

(2) 当多个接口混合的时候，也会出现一些相互调用的其他问题

2. 稳定性场景：建议也是用混合场景，一般跑8个小时，这个时候，可能出现之前没有出现的问题，比如说内存溢出

二. 单个用户并发和多个用户并发为什么效果一样？

1. 只要数据量比较多，比如用户表里有15万数据，进行同一个手机号登录的时候，也会出现性能问题

2. 就算进行参数化操作，和一个用户的效果是一样的，参数化只是为了模拟真实的情况，但是多个参数化的用户名还是会出现同样的用户进行登录

三. 定位mysql慢查询的步骤

1. 最好在做性能测试之前，对于mysql数据库，需要在/etc/my.cnf配置里配置好慢查询信息

#打开慢查询：1表示打开
slow_query_log=1
#慢查询的日志保存路径--自定义的
slow_query_log_file=/opt/mysql/mysqllog/logfile/slow-query.log
#慢查询的时间，只要达到这个时间，就会在日志里打印
long_query_time=1

注意：修改配置文件后，需要重启mysql服务：service mysqld restart

2. 跑性能测试场景，看我们场景里面的响应时间，如果一直上升并且超过了1s，TPS一直很低

3. 运行nmon，输入c，看CPU的资源使用情况，一般只要关注use%（用户态）的CPU占用，如果超过90%，一般都是慢查询语句导致的

4. 在nmon里面输入t，看是哪个进程导致的，如果mysql进程导致，一般是慢查询的问题

可以看到是mysql进程导致的，CPU使用率过高

nmon问题定位和LoadRunner结果分析_慢查询

5. 在我们的慢查询日志里面查询日志信息

输入：tail -f /opt/mysql/mysqllog/logfile/slow-query.log

6. 找到并复制日志里的sql语句：

tail -f /opt/mysql/mysqllog/logfile/slow-query.log

Query_time：查询这条语句需要多长时间

nmon问题定位和LoadRunner结果分析_mysql_02

7. 复制sql到mysql的客户端里，加上EXPLAIN查看

nmon问题定位和LoadRunner结果分析_慢查询_03

8. type=ALL，是没有索引，或者索引失效，进行全表扫描

rows：表示查找这一个条件需要查询多少行

注意：

(1) oracle数据库也有慢查询，不过是用awr报告，方法和这个有些差别

(2) nmon是监控系统资源使用情况的，要监控哪台机器就放到哪台机器上

(3) 做性能测试的时候，一定要有自己的独立性能环境，自己管理，自己部署

四. LoadRunner结果

1. 认识Analysis

nmon问题定位和LoadRunner结果分析_响应时间_04

比如事务通过率为4个9-->99.99%

Std.Deviation：标准方差，方差是描述一组数据偏离其平均值的情况

方差越大：这组数据越离散，波动性越大

方差值越小：波动性越小，也说明我们这个接口性能越稳定，处理能力比较平稳。但不能说明这个接口的性能就比较好

nmon问题定位和LoadRunner结果分析_慢查询_05

2. 90 Percent：表示90%的事务响应时间都维持在某个值附近

3. pass：与脚本做if判断的作用关联起来

nmon问题定位和LoadRunner结果分析_响应时间_06

if(atoi(lr_eval_string("{code}")) == 0) {
           lr_end_transaction("登录", LR_PASS);
       } else {
           lr_end_transaction("登录", LR_FAIL);
       }

4. Http Responses：从HTTP层面来看，发送HTTP请求成功的信息，200，并不代表事务是成功的。与Pass的数量并不一定相等

nmon问题定位和LoadRunner结果分析_mysql_07