mysql服务器io等待高定位与分析

这两天发现公司好几台阿里云ECS上的mysql生产服务器繁忙期间io等待高达百分之二三十(估计九成是没有write back),而且确定是mysql进程产生,由于跑的应用过多,开发和维护无法直接确定哪些表繁忙,哪些表不繁忙。。。

为了找到根源,我们需要知道哪些文件、表的io读写量最高,然后进行针对性的优化。

percona server原本提供了一工具pt-ioprofile,可是这工具是采用strace实现的,有可能在系统繁忙时导致进程被kill或者hang。。。所以还是通过performance_schema入手。

file_summary_by_instance表中记录了针对每个文件的Io读写情况,如下所示:

mysql> select * from file_summary_by_instance order by SUM_TIMER_WAIT desc limit 5\G;
*************************** 1. row ***************************
                FILE_NAME: /usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ioana/t1.ibd
               EVENT_NAME: wait/io/file/innodb/innodb_data_file
    OBJECT_INSTANCE_BEGIN: 139999261742528
               COUNT_STAR: 11739
           SUM_TIMER_WAIT: 1617275634994
           MIN_TIMER_WAIT: 5797000
           AVG_TIMER_WAIT: 137769394
           MAX_TIMER_WAIT: 100739635708
               COUNT_READ: 1
           SUM_TIMER_READ: 34699788
           MIN_TIMER_READ: 34699788
           AVG_TIMER_READ: 34699788
           MAX_TIMER_READ: 34699788
 SUM_NUMBER_OF_BYTES_READ: 16384
              COUNT_WRITE: 11472
          SUM_TIMER_WRITE: 1184834714832
          MIN_TIMER_WRITE: 5797000
          AVG_TIMER_WRITE: 103280406
          MAX_TIMER_WRITE: 7278810168
SUM_NUMBER_OF_BYTES_WRITE: 377339904
               COUNT_MISC: 266
           SUM_TIMER_MISC: 432406220374
           MIN_TIMER_MISC: 8252820
           AVG_TIMER_MISC: 1625586835
           MAX_TIMER_MISC: 100739635708
*************************** 2. row ***************************
                FILE_NAME: /usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ibdata1
               EVENT_NAME: wait/io/file/innodb/innodb_data_file
    OBJECT_INSTANCE_BEGIN: 139999261496128
               COUNT_STAR: 1709
           SUM_TIMER_WAIT: 814764332152
           MIN_TIMER_WAIT: 3623652
           AVG_TIMER_WAIT: 476748969
           MAX_TIMER_WAIT: 33581165152
               COUNT_READ: 166
           SUM_TIMER_READ: 22098794292
           MIN_TIMER_READ: 3623652
           AVG_TIMER_READ: 133124943
           MAX_TIMER_READ: 10389786028
 SUM_NUMBER_OF_BYTES_READ: 4784128
              COUNT_WRITE: 1215
          SUM_TIMER_WRITE: 488756864260
          MIN_TIMER_WRITE: 5788568
          AVG_TIMER_WRITE: 402268586
          MAX_TIMER_WRITE: 6710965560
SUM_NUMBER_OF_BYTES_WRITE: 364969984
               COUNT_MISC: 328
           SUM_TIMER_MISC: 303908673600
           MIN_TIMER_MISC: 7460212
           AVG_TIMER_MISC: 926550320
           MAX_TIMER_MISC: 33581165152
*************************** 3. row ***************************
                FILE_NAME: /usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ioana/t2.ibd
               EVENT_NAME: wait/io/file/innodb/innodb_data_file
    OBJECT_INSTANCE_BEGIN: 139999261741120
               COUNT_STAR: 12011
           SUM_TIMER_WAIT: 678760914098
           MIN_TIMER_WAIT: 5073956
           AVG_TIMER_WAIT: 56511264
           MAX_TIMER_WAIT: 7126760128
               COUNT_READ: 6309
           SUM_TIMER_READ: 65882736360
           MIN_TIMER_READ: 5073956
           AVG_TIMER_READ: 10442505
           MAX_TIMER_READ: 68216988
 SUM_NUMBER_OF_BYTES_READ: 103366656
              COUNT_WRITE: 5510
          SUM_TIMER_WRITE: 434740598494
          MIN_TIMER_WRITE: 5778028
          AVG_TIMER_WRITE: 78899805
          MAX_TIMER_WRITE: 7126760128
SUM_NUMBER_OF_BYTES_WRITE: 184696832
               COUNT_MISC: 192
           SUM_TIMER_MISC: 178137579244
           MIN_TIMER_MISC: 8811440
           AVG_TIMER_MISC: 927799837
           MAX_TIMER_MISC: 2063390504
*************************** 4. row ***************************
                FILE_NAME: /usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ib_logfile0
               EVENT_NAME: wait/io/file/innodb/innodb_log_file
    OBJECT_INSTANCE_BEGIN: 139999261496832
               COUNT_STAR: 258
           SUM_TIMER_WAIT: 213773061014
           MIN_TIMER_WAIT: 594456
           AVG_TIMER_WAIT: 828577331
           MAX_TIMER_WAIT: 14386901848
               COUNT_READ: 6
           SUM_TIMER_READ: 54982964
           MIN_TIMER_READ: 594456
           AVG_TIMER_READ: 9163476
           MAX_TIMER_READ: 46464536
 SUM_NUMBER_OF_BYTES_READ: 69632
              COUNT_WRITE: 141
          SUM_TIMER_WRITE: 64075588012
          MIN_TIMER_WRITE: 10415628
          AVG_TIMER_WRITE: 454436316
          MAX_TIMER_WRITE: 2400912924
SUM_NUMBER_OF_BYTES_WRITE: 149283328
               COUNT_MISC: 111
           SUM_TIMER_MISC: 149642490038
           MIN_TIMER_MISC: 1692724
           AVG_TIMER_MISC: 1348130294
           MAX_TIMER_MISC: 14386901848
*************************** 5. row ***************************
                FILE_NAME: /usr/local/mysql-5.6.19-linux-glibc2.5-x86_64/data/ib_logfile1
               EVENT_NAME: wait/io/file/innodb/innodb_log_file
    OBJECT_INSTANCE_BEGIN: 139999261497536
               COUNT_STAR: 71
           SUM_TIMER_WAIT: 128004164104
           MIN_TIMER_WAIT: 1294312
           AVG_TIMER_WAIT: 1802875432
           MAX_TIMER_WAIT: 11708167172
               COUNT_READ: 0
           SUM_TIMER_READ: 0
           MIN_TIMER_READ: 0
           AVG_TIMER_READ: 0
           MAX_TIMER_READ: 0
 SUM_NUMBER_OF_BYTES_READ: 0
              COUNT_WRITE: 48
          SUM_TIMER_WRITE: 60748006720
          MIN_TIMER_WRITE: 9237256
          AVG_TIMER_WRITE: 1265583122
          MAX_TIMER_WRITE: 2272031912
SUM_NUMBER_OF_BYTES_WRITE: 135080448
               COUNT_MISC: 23
           SUM_TIMER_MISC: 67256157384
           MIN_TIMER_MISC: 1294312
           AVG_TIMER_MISC: 2924180710
           MAX_TIMER_MISC: 11708167172
5 rows in set (0.00 sec)

在上面的查询中,我们可以看到,data/ioana/t1.ibd文件的写入是最多的。在我们的系统中,大部分情况下确实是写入的IO是瓶颈的情形比较多,主要是计算风险值实时写入所致。

找到具体的文件后,就可以根据业务模式和架构进行针对性的优化。

时间: 2024-07-30 12:28:36

mysql服务器io等待高定位与分析的相关文章

MySQL服务器 IO 100%的案例分析

[问题] 有台MySQL 5.6.21的数据库实例以写入为主,IO %util接近100% 写入IOPS很高 [分析过程] 1.通过iotop工具可以看到当前IO消耗最高的mysql线程 2.查看线程49342的堆栈,可以看到正在进行redo log的刷新,对应的是9号文件 3.9号文件对应的是redo log的第一个文件 为什么mysql进程会频繁的刷新redo log文件,要结合redolog的刷盘策略来分析,关键是innodb_flush_log_at_trx_commit参数, 默认是1

一次服务器IO占用率高的定位分析

背景:请事假在外中,听平台组同事反馈了一个问题,在往生产数据库中导入部分数据时会造成客户端的访问超时,初步定位是因为服务器磁盘占用IO过高,导数据时IO会飙升到100%,因此引起了不少数据库的慢查询操作导致客户端响应超时,无奈只好暂时停止了导入数据的脚本,同时也延误了针对这部分数据的生产测试工作.于是我第二天回到公司就投入了对这个问题的跟踪定位工作. 环境描述: 操作系统 文件系统 数据库 首先我们数据库某最大表的数据也不过300w多条,对于MySQL来说还是能够正常处理的.而且客户端并发量也不

mysql服务器参数--innodb引擎

mysql服务器参数有很多,如果想查看某一项参数的具体含义,可以使用mysqld --verbose --help | grep innodb存储引擎中的参数都是以innodb开头的: innodb_buffer_pool_size: 这个参数定义了innodb存储引擎的表数据和索引数据的最大内存缓冲区大小,和myisam存储引擎不同,myisam的key_buffer_size只缓存索引键,而innodb_buffer_pool_size却是同时为数据块和索引块做缓存,这个特性和oracle是

MySQL中使用SHOW PROFILE命令分析性能的用法整理(配合explain效果更好,可以作为优化周期性检查)

这篇文章主要介绍了MySQL中使用show profile命令分析性能的用法整理,show profiles是数据库性能优化的常用命令,需要的朋友可以参考下 show profile是由Jeremy Cole捐献给MySQL社区版本的.默认的是关闭的,但是会话级别可以开启这个功能.开启它可以让MySQL收集在执行语句的时候所使用的资源.为了统计报表,把profiling设为1 mysql> SET profiling = 1; 之后在运行一个查询 mysql> SELECT COUNT(DIS

在linux系统中跟踪高IO等待

高IO等待问题的第一个征兆通常是系统平均负载.负载均衡的计算都是基于CPU利用率的,即使用或等待CPU的进程数目,当然,在Linux平 台上,进程 几乎都处于不可中断的睡眠状态.负载均衡的基线可以解释为,在一个CPU核的机器上上,该CPU得到充分利用.因此,对于4核机器中,如果系统平均复杂为 4,表示该机器有足够的资源来处理它需要做的工作,当然只是勉强.在相同的4核系统,如果平均复杂是8,那么以为这将意味着服务器系统需要8个core才 能处理所要做的工作,但现在只有4个核,所以已经超载. 如果系

MYSQL主从不同步延迟原理分析及解决方案(摘自http://www.jb51.net/article/41545.htm)

1. MySQL数据库主从同步延迟原理.要说延时原理,得从mysql的数据库主从复制原理说起,mysql的主从复制都是单线程的操作,主 库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高,slave的Slave_IO_Running线程到主库取日志,效率很 比较高,下一步,问题来了,slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施.DML和DDL的IO操作 是随即的,不是顺序的,成本高很多,还可能可slave上的其他查询产生lo

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

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

MySQL服务器主从服务详解

MySQL主从复制概念 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从

MySQL SYS CPU高的案例分析(一)

原文:MySQL SYS CPU高的案例分析(一) [现象] 最近关注MySQL CPU告警的问题时,发现有一种场景,有一些服务器最近都较频繁的出现CPU告警,其中的现象是 SYS CPU占比较高. 下面的截图来源于“MySQL CPU报警”采集的文件 [问题分析] 可以分析出这服务器CPU升高的原因是由于表的高并发写入引起.优化方案通常是通知开发停止写入或降低写入频率. 究竟是什么原因导致高并发写入时CPU sys的占比这么高. 从采集的[Perf Stat]指标看到CPU有大量消耗是集中ke