MYSQL数据库服务磁盘IO高问题分析与优化

压力测试过程中,如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大,TPS逐渐降低等。而问题定位分析通常情况下,最优先排查的是监控服务器资源利用率,例如先用TOP 或者nmon等查看CPU、内存使用情况,然后在排查IO问题,例如网络IO、磁盘IO的问题。 如果是磁盘IO问题,一般问题是SQL语法问题、MYSQL参数配置问题、服务器自身硬件瓶颈导致IOPS吞吐率问题。

今天主要是讲解MYSQL 参数配置不合理导致在高并发下磁盘IO问题,而MYSQL整体监控优化方案后面会整理《如何轻量化MYSQL服务性能监控》文章出来。

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率一直偏高,如下案例分析讲解:

优化前

压力测试时,数据库磁盘IO使用率大于75%,响应时间1.6秒,通过NMON监控到的数据库资源使用情况,如下图一与图二:

图一:

图二

优化后

数据库服务器资源使用率:

图四

图五

1.3 优化内容

通过优化innndb等影响IO、内存的一些参数后,性能问题明显解决,优化参数内容,例如:innodb_write_io_threads、 innodb_read_io_threads、

innodb_flush_log_at_trx_commi等InnoDB 引擎优化IO 子系统参数配置若干。

原文地址:http://blog.51cto.com/372550/2073181

时间: 2024-08-06 11:14:32

MYSQL数据库服务磁盘IO高问题分析与优化的相关文章

MYSQL数据库服务CPU高问题分析与优化

MySQL服务性能监控分析与优化是永恒的主题,做为性能测试人员有时也要站在DBA角度出发进行适当分析与优化,这也是性能测试人员能长期生存发展之路.而资源的使用监控分析才是性能故障分析的根本首要任务.在数据库服务器内部,如果执行的操作会严重受到内存.CPU或磁盘吞吐量中任何一个的影响,则可以将它视为瓶颈. 因此理解服务器如何运行,资源损耗在哪些方面对问题进行故障诊断是非常有价值有意义的活动,具体案例如下. 这些监控分析优化方法等细节我们在品课学院性能实战课堂中都会以实战方式进行实操性测试监控分析实

一:MySQL数据库的性能的影响分析及其优化

MySQL数据库的性能的影响分析及其优化 MySQL数据库的性能的影响 一. 服务器的硬件的限制 二. 服务器所使用的操作系统 三. 服务器的所配置的参数设置不同 四. 数据库存储引擎的选择 五. 数据库的参数配置的不同 六. (重点)数据库的结构的设计和SQL语句 1). 服务器的配置和设置(cpu和可用的内存的大小) 1.网络和I/O资源 2.cpu的主频和核心的数量的选择 (对于密集型的应用应该优先考虑主频高的cpu) (对于并发量大的应用优先考虑的多核的cpu) 3.磁盘的配置和选择 (

【转】由浅入深探究mysql索引结构原理、性能分析与优化

摘要: 第一部分:基础知识 第二部分:MYISAM和INNODB索引结构 1.简单介绍B-tree B+ tree树 2.MyisAM索引结构 3.Annode索引结构 4.MyisAM索引与InnoDB索引相比较 第三部分:MYSQL优化 1.表数据类型选择 2.sql语句优化 (1)     最左前缀原则 (1.1)  能正确的利用索引 (1.2)  不能正确的利用索引 (1.3)  如果一个查询where子句中确实不需要password列,那就用“补洞”. (1.4)  like (2)

记一次性能测试:mysql占用磁盘IO过高 的解决过程

在一次性能测试时,发现mysql的cpu使用率不高,但是磁盘io很高, 一开始考虑是mysql的慢日志比较多,但是查看后发现慢日志并不多,而且只有一台mysql. 进入实例,查看sync_binlog变量 mysql> show variables like '%sync_binlog%' -> ; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | sync_binlog | 1 |

磁盘IO高和线程切换过高性能压测案例分析

案例现象: 压力测试的时候,发现A请求压力80tps后,cpu占用就非常高了(24核的机器,每个cpu占用率全面飙到80%以上),且设置的检查点没有任何报错. 1.top命令如下: 2. 了解了一下后台实现逻辑:大体是这样的:服务器接到请求后,会再到另一台kv服务器请求数据,拿回来数据后,根据用户的机器码做个性化运算,最后将结果返回给客户端,期间会输出一些调试log. 查了下,kv服务器正常,说明是本机服务服务器的问题.具体用vmstat命令看一下异常的地方. 3. 从图中可以直观的看出,bi.

一次磁盘IO高的问题处理

问题现象: 开发测试环境的kubernetes master服务器,磁盘读写速率很高,达200多M/s,IOPS超过8000/S,系统操作出现卡顿(还好硬盘是SSD,否则系统早卡死掉了),截图如下: 解决思路: 1.使用iotop查看IO高的进程,并kill,问题依旧 2.重启系统后正常,但一段时间后问题重现 3.查看内存,发现物理内存已基本使用完,并且在大量使用swap,因此问题原因可以确定: IO高是因为进程大量使用swap交换页所导致!!! 注:因为是开发测试环境,没有部署监控.分配的资源

【mysql】关于IO/内存方面的一些优化

这里使用的是mysql  Ver 14.14 Distrib 5.6.19, for Linux (i686) using  EditLine wrapper 一.mysql目录文件 ibdata1:系统表空间 包含数据字典.回滚日志/undolog等 (insert buffer segment/double write segment/rollback segment/index segment/dictionary segment/undo segment) ib_logfile0/ib_

mysql索引结构原理、性能分析与优化

原文  http://wulijun.github.com/2012/08/21/mysql-index-implementation-and-optimization.html 第一部分:基础知识 索引 官方介绍索引是帮助MySQL高效获取数据的数据结构.笔者理解索引相当于一本书的目录,通过目录就知道要的资料在哪里, 不用一页一页查阅找出需要的资料. 唯一索引(unique index) 强调唯一,就是索引值必须唯一. 创建索引: create unique index 索引名 on 表名(列

由浅入深探究mysql索引结构原理、性能分析与优化

转载自:http://www.phpben.com/?post=74 第一部分:基础知识: 索引 官方介绍索引是帮助MySQL高效获取数据的数据结构.笔者理解索引相当于一本书的目录,通过目录就知道要的资料在哪里,不用一页一页查阅找出需要的资料.关键字index ------------------------------------------------------------- 唯一索引 强调唯一,就是索引值必须唯一,关键字unique index 创建索引: 1.create unique