RDS实例的性能测试报告----基础总结篇-CSDN博客

1ãÂ 首先登录DT，云数据库，通过bic子系统定位到生产上RDS的主实例ID，复制主实例的id到杜康上具体查看RDS的性能问题

2ãÂ 杜康点击实例诊断，实例性能信息，筛选时间12-13 16:30-17:30 的性能信息

a) 磁盘空间、磁盘空间详情：这段时间的数据是一条直线，空间状态都很稳定，没有性能问题。

MySQL RDS磁盘占用包括日志文件（binlog文件、错误日志等），数据文件（数据、索引文件），和一些其他文件（ibdata，logfile_0,临时文件等）

造成 MySQL 实例空间使用率过高，主要有如下四种原因：

Binlog 文件占用高。

数据文件占用高。

临时文件占用高。

系统文件占用高。

对应解决方法：

1、定期删除binlog，假如当前dml造成大量的binlog，可以通过RDS控制台即使清理binlog

2、通过truncate或者drop及时清除不需要的表

3、终止对应的回话

4、ibdata中undo占用高可以进行undo分离，或者进行数据转移；增加redo log file的大小和组数

b) IOPS：每秒读写的次数。现在是比较小的。在0-0.2之间。

如果IOPS比较高的话，有可能是以下原因：

1、实例内存满足不了缓存数据或排序等需要，导致产生大量的物理 IO。

2、查询执行效率低，扫描过多数据行。

解决方法：

1、查询是否有慢SQL，优化慢SQL，可以参考杜康的实例卡慢诊断的优化建议，或者登录DMS，通过诊断报告、优化来进行SQL优化

2、终止查询语句

3、通过show processlist，或者DMS控制台、杜康等来kill查询回话id

c) MySQL内存使用率：基本上是一条直线，没有变化。因为MySQL有innodb_buffer_pool，大约为物理内存的50%-80%，内存使用率高一些，相对的性能也会提高

d) 物理内存：直线保持基本无变化，物理内存就是实际的内存条的内存大小

e) 连接数：当前连接数在1500左右，后来增高至6000左右。但是活跃连接数一直在个位数，说明现在的空闲连接数过多。总连接数超过参考值2000。出现严重问题。

数据库的连接一般是使用长连接，可能是应用侧的连接池初始连接数设置过高，应用启动后建立多个到RDS的空闲连接

解决方法：
1、长连接建议启用连接池的复用连接功能。

2、对于交互式连接和非交互式连接，建议修改相应的wait_timeout和interactive_timeout参数。（空闲时间超过指定的时间后，RDS的连接会主动关闭）。通过DT，RDS控制台，性能优化，参数设置中修改。

3、kill当前的空闲会话。

f) 线程状态：线程数跟连接数是对应的。此时也是连接的总线程数远大于活跃的线程数。

g) 备库延迟：目前主备延迟(slave-lag)为0.

主备延迟产生的原因：

1ãÂ 主库产生非常大的binlog

a) 主库上执行大量的dml语句

b) 主库上执行大事务

c) 主库上没有主键的全表扫描

2ãÂ 主库上执行ddl语句，时间过长

3ãÂ 备库上对myisam表长时间查询，阻塞主库的binlog同步语句

4ãÂ 备库实例的规格配置低，磁盘IO比较低

查看方法:

1ãÂ 首先查看备库的IOPS是否存在瓶颈

2ãÂ 备库show processlist查看是否存在大事务

3ãÂ 主库的写入压力是否过高，dml语句是否过多

4ãÂ 只读节点执行 show slave status \G，判断是否有 Waiting for table metadata lock；同时在主库排查下是否有DDL 操作

5ãÂ 只读节点执行 show slave status \G，判断是否有 Waiting for table level lock; 同时通过 show full processlist; 同时在主库检查下是否有长时间对 MyISAM 引擎表的查询

h) QPS/TPS：QPS比较高，在90000左右，最高到达110000 。每秒的事务数在10000以上。正常，业务量比较高

原因分析：

QPS比较高，每秒SQL的语句执行次数高，业务量上来，处于业务的高峰期，用户连接数增加，访问量增加。

如果QPS比较高，逻辑读不高，慢SQL也不是系统的瓶颈，QPS和cpu使用率的变化曲线吻合，这时候优化的余地就不高了，可以从实例规格、应用架构方面进行考虑。

如果QPS不高，查询执行效率低、执行时需要扫描大量表中数据、优化余地大，并且出现慢查询问题，QPS和CPU的变化曲线不吻合

如果QPS比较高，并且逻辑读也比较高，CPU的使用率增加，这时候可以优化优化相应的慢SQL，添加主实例的只读实例来缓解压力。

I ) cpu/mem的使用率：现在cpu的使用率在30%左右，不算高。内存的使用率基本平稳在30%左右，正常

CPU的使用率高的原因：

系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读，（逻辑 IO，执行查询所需访问的表的数据行数），需要消耗大量的 CPU 资源以维护从存储系统读取到内存中的数据一致性。造成逻辑读高的原因，很可能是异常SQL，扫描的数据行数过多导致。

j) 慢SQL：慢SQL数量的变化曲线跟CPU的使用率的变化曲线吻合，在CPU使用率高的时候，慢SQL也跟着增加。可以通过杜康对产生的慢SQL进行优化。

K) 全表扫描次数：随着业务量的增加，全表扫描的次数也随之增加。Sql要尽量避免全表扫描

主实例问题与建议：

QPS升高，业务量高的情况下，产生一些慢查询SQL，并且空闲连接数太多

Â Â 1ãÂ 连接数：连接数严重超过参考值，并且有过多的空闲线程。首先检查应用是否使用连接池，如果使用连接池，检查连接池的配置是否合理

Â Â 2ãÂ 优化慢SQL

select id , inst_id , code , name_cn , aic_register_name , postcode , administrative_division , province_code , city_code , status , business_unit , org_level , org_category , manage_level , parent_org_code , distribution_org_flag , legal_entity_flag , address , approve_create_date , source_org_create_date , major , org_phase , main_category , detail_category , business_function , core , corporation_flag , department_flag , company_code , company_name , common_service , branch_emp_relationship , branch_urban_type , branch_func_type , branch_invest_type , create_date , modify_date , create_user_id , gmt_created , modify_user_id , gmt_modified , is_deleted from bic_base_org

优化建议：此类SQL没有where条件，一定要添加where条件并且有合适的索引。这样会造成全表扫描影响系统性能。如果一定要执行建议在业务低峰期执行

select count ( * ) as cnt from ( select id , jdpt_employee_code , td_employee_code , td_employee_name , td_org_code , td_org_name , td_phone_number , td_id_number , td_employee_status , td_employee_role , create_user_id , gmt_created , modify_user_id , gmt_modified , is_deleted from bic_td_jdpt_employee_relation where :1 = :2 and is_deleted = :3 )

优化建议：此类SQL扫描行与发送行的比666184，并且查询使用了聚合函数，没有使用where条件。影响服务器性能，SQL锁行过多，可能影响其他更新语句。关联列上添加索引，子查询返回的行数尽量少

个人总结：

针对RDS的问题：CPU占有率持续高、QPS持续高、逻辑读一直高，用户连接线程增加，活跃线程数增加。

一般情况下：有慢SQL的情况，首先优化慢SQL，针对慢SQL主要注意查询多少数据和返回多少数据，如果查询的数据跟反回的数据都比较大，而且执行时间秒级别特别长，很有可能是慢SQL；没有慢SQL，或者慢SQL不是性能主导原因的话，可以考虑实例的规格配置和实例的架构，比如增加主实例的规格配置，增加只读实例缓解主实例的压力等。