标签：合并 repo cap 调度 大量 red data 就是 解决办法
一 简介 谈谈磁盘IO的问题二 目的:如何进行IO性能问题的排查
二 linux角度
一 基本定义
寻道时间，表示磁头在不同磁道之间移动的时间。
旋转延迟，表示在磁道找到时，中轴带动盘面旋转到合适的扇区开头处。
传输时间，表示盘面继续转动，实际读取数据的时间
二 机械硬盘
随机读写 1 需要多次寻道和旋转延迟(非常消耗时间) 2 不会预读
顺序读写 1 传输时间 2 会预读
三 SSD固态硬盘
1 固态硬盘没有普通硬盘的机械结构,也不存在机械硬盘的寻道问题.就是随机读写的能力远远高于机械硬盘
2 SSD 优化
linux角度
1 IO调度器选择noop算法
2 选择xfs或者ext4文件系统,推荐xfs
mysql角度
控制脏页刷新
1 innodb_flush_neighbors 设置为0 关闭该特性
2 innodb_io_capacity 脏页刷新数量,建议设置为iops的60%,如果设置的过低,会限制tps的能力,如果设置的过高,会加大磁盘io的压力,因为一次性刷新的脏页数量会多
参数说明
当刷新一个脏页时，innodb存储引擎会检测该页所在区(extent)的所有页，如果是脏页，那么一起进行刷新,这样做能合并多个IO,减少硬盘压力
建议 机械硬盘开启 SSD硬盘关闭
四 压测
1 压测磁盘组的随机读写能力
fio -filename=/data/d.txt -direct=1 -iodepth 1 -thread -rw=randrw -ioengine=psync -bs=16k -size=1500M -numjobs=40 -runtime=10 -group_reporting -name=mytest
关心参数
read and write的iops
2 通过压力测试得出服务器的最大承受值
请注意:util并不能真正反映磁盘组的整体性能,反过来,util值忙,代表磁盘繁忙程度,想要看磁盘压力,观察iowait.
三 mysql角度
一 事务
1 写日志文件
1 流程 redo log+binlog 二阶段提交-> 写日志文件 顺序写
2 控制参数
innodb_flush_log_at_trx_commit = 1 控制redo log的磁盘刷新
sync_binlog = 1 控制binlog 的磁盘刷新
2 脏页刷新
1 将内存中改变的数据页刷新到磁盘中
2 控制参数
innodb_flush_neighbors 控制相邻脏页的刷新
innodb_io_capacity 控制脏页刷新的数量
二 查询
1 慢语句
使用索引不当的慢sql查询会造成磁盘的繁忙,这种情况多出现在
1 大表的慢sql查询
2 表的主键碎片化也会造成大量的随机读,常见于uuid作为主键或者执行过大量更改的情况
3 单个慢sql出现在慢日志,慢sql本身受到影响(1 脏页刷新 2 日志刷新 3 并发sql查询)
2 并发语句
大量并发语句并发查询导致的磁盘繁忙情况
四 判断分析
磁盘没有到达瓶颈
1 根据上文提出的,要分析mysql哪一部分出了问题,日志刷新->脏页刷新->慢日志,根据某一个环节进行优化
磁盘到达瓶颈
1 mysql慢日志出现了很多不该出现的慢日志语句,通常表现在扫描行数很少,单体执行很快
2 监控图的iops经常性报警,尤其是在业务高峰期,由于IO限制导致的负载升高,iowait值很高
解决办法:1 拆分业务 2 做读写分离 3 升级硬盘,采用ssd硬盘
五 补充
分析数据库的IO问题 可以采用 pt-ioprofile定位文件信息
标签：合并 repo cap 调度 大量 red data 就是 解决办法
原文地址：https://www.cnblogs.com/danhuangpai/p/10101130.html
