RDS实例的性能测试报告----基础总结篇-阿里云开发者社区

开发者社区> 数据库> 正文

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

简介: 新手的认识和总结,有不对的地方请多多指教。

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

a)

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条件并且有合适的索引。这样会造成全表扫描影响系统性能。如果一定要执行建议在业务低峰期执行

b)

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不是性能主导原因的话,可以考虑实例的规格配置和实例的架构,比如增加主实例的规格配置,增加只读实例缓解主实例的压力等。



版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章