FAQ系列 | 是什么导致MySQL数据库服务器磁盘I/O高?

标签: 运维经验 MySQL数据库 | 发表时间:2016-11-17 02:37 | 作者:小码哥
出处:http://www.yunweipai.com

0、导读

有个MySQL服务器的磁盘I/O总有过高报警,怎么回事?

1、问题

我的朋友小明,TA有个MySQL服务器最近总是报告磁盘I/O非常高,想着我这有免费的不用白不用的企业技术服务(TA自己这么想的),就找我帮忙给把把脉。

作为一个经验丰富(踩坑不断)的DBA,出现这种问题,一般来说,磁盘I/O很高无非是下面几个原因引起:

磁盘子系统设备性能差,或采用ext2/ext3之类文件系统,或采用cfq之类的ioscheduler,所以IOPS提上不去;

SQL效率不高,比如没有索引,或者一次性读取大量数据,所以需要更多的I/O;

可用内存太小,内存中能缓存/缓冲的数据不多,所以需要更多的I/O。

方法论已有,接下来就是动手开始排查了。

2、排查

先看磁盘I/O设备,是由十几块SSD组成的RAID10阵列,按理说I/O性能应该不至于太差,看iops和%util的数据也确实如此。

磁盘I/O设备

再来看下文件系统、io scheduler的因素,发现采用xfs文件系统,而且io scheduler用的是noop,看来也不是这个原因。而且看了下iostat的数据,发现iops也不算低,说明I/O能力还是可以的。

文件系统

再来看看当前的processlist,以及slow query log,也没发现当前有特别明显的slow query,所以也不是这个原因了。

processlist

现在只剩下内存不足这个因素了,看了下服务器物理内存是64G,用系统命令 free 看了下,发现大部分都在cached,而free的也不多。观察InnoDB相关的配置以及status,看能不能找到端倪。

首先,看下 innodb-buffer-pool-size 分配了多少:

innodb-buffer-pool-size

嗯,分配了18G,好像不是太多啊~

再看一下 innodb status:

分配

重点关注下几个wait值,再看下show engine innodb结果:

wait值

关注下unpurge列表大小,看起来还是比较大的(有111万)。

更为诡异的是,在已经停掉SLAVE IO & SQL线程后,发现redo log还在一直增长...

第一次看

SLAVE IO & SQL线程

停掉SLAVE线程后过阵子再看

SLAVE线程

看到这里,有经验的DBA应该基本上能想明白了,主要是因为 innodb buffer pool 太小,导致了下面几个后果:

  1. dirty page 和 data page 之间相互“排挤抢占”,所以会出现 Innodb_buffer_pool_wait_free 事件;
  2. redo log 也没办法及时刷新到磁盘中,所以在SLAVE线程停掉后,能看到LSN还在持续增长;
  3. 同时我们也看到unpurge的列表也积攒到很大(111万),这导致了ibdata1文件涨到了146G之大,不过这个可能也是因为有某些事务长时间未提交。

还有,不知道大家注意到没,Innodb_row_lock_current_waits 的值竟然是 18446744073709551615(想想bigint多大),显然不可能啊。事实上,这种情况已经碰到过几次了,明明当前没有行锁,这个 status 值却不小,查了一下官方bug库,竟然只报告了一例,bug id是#71520。

3、解决

既然知道原因,问题解决起来也就快了,我们主要做了下面几个调整:

  • 调大innodb-buffer-pool-size,原则上不超过物理内存的70%,所以设置为40G;
  • 调大innodb-purge-thread,原来是1,调整成4;
  • 调大innodb_io_capacity和innodb_io_capacity_max,值分别为2万和2.5万;

调整完后,重启实例(5.7版本前调整innodb-buffer-pool-size 和 innodb-purge-thread 需要重启才生效)。再经观察,发现IOPS下降的很快,不再告警,同时 Innodb_buffer_pool_wait_free 也一直为 0,unpurge列表降到了数千级别,搞定,收工,继续搬砖卖茶~

作者:叶金荣

文章出处:老叶茶馆(订阅号ID:iMySQL_WX)

相关 [faq 系列 mysql] 推荐:

[MySQL FAQ]系列 -- mysqldump选项之skip-opt

- - MySQL 中文网
最近在用mysqldump备份时,想要把数据表和数据分开备份,因此做了2次备份. 执行备份数据库表结构时,指定了 --skip-opt 选项,相当于:. 选项 --create-option 看起来比较不起眼:. 事实上,如果把它disable的话,备份出来的表结构,会少了:. 等MySQL特有的数据表属性,需要注意下.

[MySQL FAQ]系列 -- 几种常见MySQL无法启动案例

- - MySQL 中文网
昨天在群里看到有新同学还在问MySQL无法启动的问题,于是总结了几个常见情况,权当普及帖了,老鸟自觉飞过. 问题1:目录、文件权限设置不正确. MySQL的$datadir目录,及其下属目录、文件权限属性设置不正确,导致MySQL无法正常读写文件,无法启动. 已有其他mysqld实例启动,且占用了相同端口,需要修改 port 选项.

[MySQL FAQ]系列 — MySQL复制中slave延迟监控

- - MySQL中文网
在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟. 这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素. 首先,我们先看下SLAVE的状态:. 可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延迟了 3296 秒.

[MySQL FAQ]系列 -- 新手必看:一步到位之InnoDB

- - MySQL 中文网 -
前言:MySQL发展到今天,InnoDB引擎已经作为绝对的主力,除了像大数据量分析等比较特殊领域需求外,它适用于众多场景. 然而,仍有不少开发者还在“执迷不悟”的使用MyISAM引擎,觉得对InnoDB无法把握好,还是MyISAM简单省事,还能支持快速COUNT(*). 本文是由于最近几天帮忙处理discuz论坛有感而发,希望能对广大开发者有帮助.

[MySQL FAQ]系列 — 为什么要关闭query cache,如何关闭

- - MySQL中文网
备注:插图来自淘宝苏普的博客并保留水印,如果觉得不当还请及时告知 :). 写在前面:MySQL的query cache大部分情况下其实只是鸡肋而已,建议全面禁用. 当然了,或许在你的场景下还是挺好的,还能发挥作用,那就继续使用吧,把本文当做参考就好. 不过,可能有的人人为只需要把 query_cache_size 大小调整为 0 就可以了,可以忽略 query_cache_type 参数的值,反正它也是可以在线调整的.

[MySQL FAQ]系列 — processlist中哪些状态要引起关注

- - MySQL中文网
插图来自网络并作简单加工,如果觉得不当还请及时告知 :). 一般而言,我们在processlist结果中如果经常能看到某些SQL的话,至少可以说明这些SQL的频率很高,通常需要对这些SQL进行进一步优化. 今天我们要说的是,在processlist中,看到哪些运行状态时要引起关注,主要有下面几个:.

[MySQL FAQ]系列 — profiling中要关注哪些信息

- - MySQL中文网
利用MySQL的PROFILE功能,我们可以很方便的查看一个SQL具体的执行代价是怎样的,尤其是可以分析它的最大瓶颈在哪里. 目前PROFILE功能可提供除了内存以外的其他资源消耗统计,例如CPU、I/O、CONTEXT、SWAP等. PROFILE功能只能在SESSION级别使用,还做不到像SQL Server那样可以全局开启,收集一段时间后再关闭,这点有待改进.

[MySQL FAQ]系列 — 线上环境到底要不要开启query cache

- - MySQL中文网
Query Cache(查询缓存,以下简称QC)存储SELECT语句及其产生的数据结果,特别适用于:频繁提交同一个语句,并且该表数据变化不是很频繁的场景,例如一些静态页面,或者页面中的某块不经常发生变化的信息. InnoDB Buffer Pool或者. MyISAM key buffer里读取结果.

[MySQL FAQ]系列 — 为什么InnoDB表要建议用自增列做主键

- - MySQL中文网
我们先了解下InnoDB引擎表的一些关键特征:. InnoDB引擎表是基于B+树的索引组织表(IOT);. 每个表都需要有一个聚集索引(clustered index);. 所有的行记录都存储在B+树的叶子节点(leaf pages of the tree);. 基于聚集索引的增、删、改、查的效率相对是最高的;.