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是瓶颈的情形比较多,主要是计算风险值实时写入所致。
找到具体的文件后,就可以根据业务模式和架构进行针对性的优化。
mysql服务器io等待高定位与分析的更多相关文章
- MySQL服务器 IO 100%的案例分析
[问题] 有台MySQL 5.6.21的数据库实例以写入为主,IO %util接近100% 写入IOPS很高 [分析过程] 1.通过iotop工具可以看到当前IO消耗最高的mysql线程 2.查看线程 ...
- MySQL服务器 IO 100%的分析与优化方案
前言 压力测试过程中,如果因为资源使用瓶颈等问题引发最直接性能问题是业务交易响应时间偏大,TPS逐渐降低等.而问题定位分析通常情况下,最优先排查的是监控服务器资源利用率,例如先用TOP 或者nmon等 ...
- MySQL服务器发生OOM的案例分析
[问题] 有一台MySQL5.6.21的服务器发生OOM,分析下来与多种因素有关 [分析过程] 1.服务器物理内存相对热点数据文件偏小,62G物理内存+8G的SWAP,数据文件大小约550G 触发OO ...
- 服务器IO瓶颈对MySQL性能的影响
[背景] 之前我们碰到一些MySQL的性能问题,比如服务器日志备份时可能会导致慢查询增多,一句简单的select或insert语句可能执行几秒,IO负载较高的服务器更容易出现并发线程数升高,CPU上升 ...
- mysql 服务器负载过高的解决分析之路
最近我们有台 mysql 服务器一直报负载过高,不停的收到阿里云的报警短信,让我很抓狂,登陆上服务器,看下一下,慢查询日志 发现有60多万的慢查询日志,一看这个就知道是搜索带来的,一直想把搜索的服务给 ...
- 服务器负载过高问题分析-不是cpu高负载也不是IO负载如何处理(阿里 几乎是必考题)
关于top命令 经常问load average 参考:load average 定义(网易面试) jvm dump的使用 参考:Jvm dump jstack jmap jstat 介绍与使用(内存与 ...
- MYSQL服务器my.cnf配置文档详解
MYSQL服务器my.cnf配置文档详解 硬件:内存16G [client] port = 3306 socket = /data/3306/mysql.sock [mysql] no-auto-re ...
- 谈谈MySQL无法连接的原因和分析方法
[可能的原因] MySQL无法连接的原因有很多,比如: 1.数据库的请求量突增,实例连接数超过max_connections,或用户连接数超过max_user_connections, 这种情况连接时 ...
- 1104关于优化mysql服务器几个参数和思路
转自http://www.cnblogs.com/AloneSword/p/3207697.html 按照从大到小,从主要到次要的形式,分析 mysql 性能优化点,达到最终优化的效果. 利用 min ...
随机推荐
- 关于STM32 CAN回环可用,正常不可用情况分析
1.回环下应该与GPIO无关 2.GPIO是否初始化正确,时钟启用 3.是否复用,AFIO时钟是否启用 4.回环下是否有CAN_Tx应该有输出 5.终端电阻是否有 6.CAN收发器电路电压是否正常 7 ...
- 最近一直在搞CAE,发现Eplan p8真的好强大。
最近一直在搞CAE,发现Eplan p8真的好强大. 标准化的意义在与提高工作效率,减少重复. 标准化后,不容易出错,项目更改容易.事件都能及时跟踪.
- myeclipse不编译解决方法
在开发中经常遇到myeclipse不编译的情况,但不同情况的解决方法又不一样,今天同样是遇到此类情况,在网上狂搜,终于找到一篇好文,它囊括了解决这种情况的常用的方法,现在发出来与大家分享.我遇到的情况 ...
- Java 监控请求
监控对象 import java.util.Date; import java.util.HashMap; import java.util.Map; import java.util.Map.Ent ...
- JAVA和C# 3DES加密解密
最近 一个项目.net 要调用JAVA的WEB SERVICE,数据采用3DES加密,涉及到两种语言3DES一致性的问题, 下面分享一下, 这里的KEY采用Base64编码,便用分发,因为Java的B ...
- 代码演示 .NET 4.5 自带的 ReadonlyCollection 的使用
代码如下: 1. using System; using System.Collections.Generic; using System.Linq; using System.Text; using ...
- 重识JavaScript 之 JavaScript的组成
JavaScript由ECMAScript.DOM.BOM组成. 简单认识: ECMAScript:首先它不是一门编程语言,而是一个标准,规定这些浏览器的脚步语言必须按照它的规定去做. DOM ...
- C#连接Oracle简单教程
要点:本文主要介绍如何使用最简单的方法让C#操作Oracle数据库,不需要安装Oracle客户端之类的东西. 最近由于工作需要,要使用C#从SQLServer向Oracle导入数据.之前没有怎么接触过 ...
- MySQL安全问题(防范必知)
对于任何一种数据库来说,安全问题都是非常重要的.如果数据库出现安全漏洞,轻则数据被窃取,重则数据被破坏,这些后果对于一些重要的数据库都是非常严重的.下面来从操作系统和数据库两个层对MySQL的安全问题 ...
- 【转】SAPI中的IspeechRecoContext(接口)
IspeechRecoContext自动化接口定义一个识别上下文. 什么是一个识别上下文? 一个识别上下文就是应用程序和SAPI共同作用来实现语音识别的最主要方法.它就是用来允许应用程序来开始.停止识 ...