压力测试过程中, 因为资源使用瓶颈等问题引发的最直接的性能问题是业务交易响应时间偏大, TPS 逐渐降低等. 而问题定位分析通常情况下, 最优先排查的是监控服务器资源利用率, 例如先用 TOP 或者 nmon 等查看 CPU, 内存使用情况, 然后在排查 IO 问题, 例如网络 IO, 磁盘 IO 的问题.
Part 1
- 前言 -
压力测试过程中, 因为资源使用瓶颈等问题引发的最直接的性能问题是业务交易响应时间偏大, TPS 逐渐降低等. 而问题定位分析通常情况下, 最优先排查的是监控服务器资源利用率, 例如先用 TOP 或者 nmon 等查看 CPU, 内存使用情况, 然后在排查 IO 问题, 例如网络 IO, 磁盘 IO 的问题. 如果是磁盘 IO 问题, 一般问题是 SQL 语法问题, MYSQL 参数配置问题, 服务器自身硬件瓶颈导致 IOPS 吞吐率问题.
今天主要是讲解 MYSQL 参数配置不合理导致在高并发下磁盘 IO 问题.
Part 2
- 三种问题 -
1, 打开日志跟踪引起的磁盘 IO 问题
例如: MySQL 的日志包括错误日志 (ErrorLog), 更新日志(UpdateLog), 二进制日志(Binlog), 查询日志(QueryLog), 慢查询日志(SlowQueryLog) 等, 正常情况下, 在生产系统或者压力测试环境中很少有系统会时时打开查询日志. 因为查询日志打开之后会将 MySQL 中执行的每一条 Query 都记录到日志中, 会该系统带来比较大的 IO 负担, 而带来的实际效益却并不是非常大.
2, SQL 写法问题引起磁盘 IO 高
例如: 曾经在做某一个项目时, 在看到数据库磁盘 IO 使用率偏高, 前端查询业务交易 loadrunner 显示事物响应时间偏长, 通过监控工具抓取对应 SQL, 通过计划分析, 发现该 SQL 中使用 distinct 又多表关联且是大表, 然后使用 order by, 最终显示 10 笔数据, 而在产生中间过程数据进行筛选时, 使用的是临时表, 并把数据放入临时表中, 内存刚好设置不大, 于是放到磁盘中导致 IO 偏高.
备注: MySQL 在执行 SQL 查询时可能会用到临时表, 临时表存储, MySQL 会先创建内存临时表, 但内存临时表超过配置指定的值后, MySQL 会将内存临时表导出到磁盘临时表.
3, MYSQL 参数配置问题
MYSQL 默认配置性能低下, 只能通过并发下尝试调整参数配置来逐步优化数据库性能, 2017 年底根据公司要求配合帮助某一家银行业务系统做性能测试, 因为测试环境硬件资源有限, 我跟公司申请了几台过时的笔记本, 然后根据生产环境软件版本等配置要求, 进行模拟搭建性能测试环境, 基础软件包含: MYSQL5.6,centos7.2,tomcat7, JDK1.7,redis. 使用的是联想 L421 笔记本当 MYSQL 数据库服务器, L440 当 tomcat 应用服务器, 压力测试工具 loadrunner, 并发用户 100, 压力测试业务场景: 用户登录退出, 相关票据信息查询, 电子汇票交易流程等, 在压力测试过程中发现部分交易在 50 用户并发时, 数据库磁盘 I0 使用率都偏高, 特别是写操作一直很高, 例如测试登录退出交易, 经监控数据库磁盘 IO 率一直偏高, 下面我将以此为例作为讲解.
Part 3
- 优化前后 -
优化前
压力测试时, 数据库磁盘 IO 使用率大于 75%, 响应时间 1.6 秒, 通过 NMON 监控到的数据库资源使用情况, 如下图一与图二:
图一:
图二:
优化后
数据库服务器资源使用率:
图三:
图四:
Part 4
- 优化内容 -
通过优化 innndb 等影响 IO, 内存的一些参数后, 性能问题明显解决, 优化参数内容, 例如: innodb_write_io_threads,innodb_read_io_threads,innodb_flush_log_at_trx_commi 等 InnoDB 引擎优化 IO 子系统参数配置若干.
来源: http://server.51cto.com/BigData-578912.htm