服务器磁盘突然写入巨慢问题

关机十分钟后才能缓解的影响因素我只能想到是温度

有，但不是大佬，也不是 MyISAM 。
线上业务，单表 20 多 G ，删除 5GB 左右的数据，3 个小时，症状：
查询正常（大部分走从机）写入延迟 2~3 秒。
主机监控 CPU 狂飙，IO 使用率狂飙。
执行完后从机重复上面症状，并且主从同步延时拉扯到 13 秒。
等从机执行完后手动 alert 了一下表触发 optimize 操作。
大概 30 分钟，监控看到的是 CPU 和磁盘使用率一直升。
后来经过百度查询到由于 optimize 的时候 mysql 是创建一份新的数据，再物理删除旧的数据。

@markgor 感觉还是不太一样，我这边的情况 cpu 是正常的，并且 optimize 早就执行完了，不是 optimize 过程中出现的
比如这次出现的问题，5 月 1 号 晚上执行的 optimize ，到今天 3 号磁盘都还是写不动，optimize 肯定是早执行完了

@neutrinos 10 平米的机房 2 台空调 24 小时开着，温度应该没问题

1.不跑任何业务的情况下，磁盘的性能？

单线程连续读，单线程连读写，单线程随机读，单线程随机写，64 线程随机读，64 线程随机写？

建议测试工具：
fio

例子：

# 安装
yum install epel-release -y
yum install fio -y

mkdir -p /tmp/diskTest
cd /tmp/diskTest

# 顺序写，单进程：
fio --name=SeqWrite --ioengine=libaio --iodepth=1 --rw=write --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Seq8G.testData

# 顺序读，单进程：
fio --name=SeqRead --ioengine=libaio --iodepth=1 --rw=read --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Seq8G.testData

# 随机写，单进程：
fio --name=RandWrite1Process --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Rand1Process8G.testData

# 随机读，单进程：
fio --name=RandRead1Process --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Rand1Process8G.testData

# 随机写，64 进程：
fio --name=RandWrite64Process --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=64 --group_reporting --filename=Rand64Process8G.testData

# 随机读，64 进程：
fio --name=RandRead64Process --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=64 --group_reporting --filename=Rand64Process8G.testData

# 如果测试时间过段，请加大上面关于容量的参数 --size ，每次加两倍。

这个步骤，是让你自己，裸磁盘与分区的大致性能，看看磁盘或 raid 是否存在问题。

比如，正常情况下，普通民用 HDD ，单线程随机写，速度大概是 1.41 MB/s 。

对比，某物理服务器，对 4 个机械硬盘，做了 3 副本纠删码，单线程随机写，性能降到 0.2 MB/s ，这里就需要优化了，不然客户会骂街。



2.老哥你的监测指标，少了一个非常重要的参数：分区与物理硬盘的 %utill ，也就是磁盘负载，就像 CPU 负载一样，值越高说明磁盘压力越大。

命令：
iostat -x -m -d 1

说明：
物理磁盘的 %utill ，指的是每块物理磁盘的负载。

分区的 %utill ，指的是，有些分区是有多个物理磁盘组成。此时分区的 %utill 也很重要。



3.上述指标，配合 iotop 命令，基本上能定位到进程。

4.最后，用命令：
strace -f -t -e trace=file -p <PID>

来跟踪进程的 IO ，看它到底在干啥。

@AnjingJingan #3 又重新认证看了下监控图，
每次写入慢=IO 100%
我觉得排障的流程应该变为：
IO 写入慢----此刻发生了什么事？是哪个进程 IO 导致 100%?
如果日志看不出来，建议可以设定监控，IO 持续 2 分钟 90%以上告警，然后远程进入看哪进程导致的。
另外可以看看 raid 卡日志，看看那个时间有没异常。

另外如 1#提及到的，涉及关机 10 分钟后才正常的好像也只有温度问题了。
如果你是用板载 raid 那很大因素是这样。
特别是 X58 的南桥芯片组，就算不 raid 温度也感人。
所以你想早日解决，建议：

1 、增加硬件温度监控；--先确定是否硬件问题
2 、做好告警，触发时候第一时间去“现场”查看凶手

碎片整理是这样的。

另外温度的确要检测一下，各物理磁盘温度，各 CPU 温度，主板温度，等等。打上时间戳，放入运维系统。

当出现问题时，看看各设备的温度。

先看 IO 延时，高的话，看是 IOPS 高还是吞吐量高，要都不高的话可能是硬件问题，要有一项高的话就 iotop,strace 什么的寻找占用高的进程。

重启跟关机再开机有区别，重启是不断电的，会跳过不少硬件检查程序

所以等待十分钟可能是不必要的，可能只是需要关机断电再开机通电。复现问题，关机再开机，如果立即恢复了就可以排除温度过高的可能

raid5 写性能很差，数据库要 IO 还是得上 Raid10 。

* 是固定日期发生问题么？ 查下是不是 raid 的 Consistency Check 搞的鬼 https://www.gillware.com/raid-data-recovery/common-raid-performance-killers-consistency-checks/

@documentzhangx66 感谢老哥提供思路，磁盘在正常状态下没问题的，4 块物理盘是 Intel S3520 ，业务再跑的时候测了一下速：
```
顺序写单进程
fio --name=SeqWrite --ioengine=libaio --iodepth=1 --rw=write --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Seq8G.testData
结果：
WRITE: io=4096.0MB, aggrb=906288KB/s, minb=906288KB/s, maxb=906288KB/s, mint=4628msec, maxt=4628msec

顺序读单进程
fio --name=SeqRead --ioengine=libaio --iodepth=1 --rw=read --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Seq8G.testData
结果：
READ: io=4096.0MB, aggrb=586042KB/s, minb=586042KB/s, maxb=586042KB/s, mint=7157msec, maxt=7157msec

随机写单进程
fio --name=RandWrite1Process --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Rand1Process8G.testData
结果：
WRITE: io=4096.0MB, aggrb=63519KB/s, minb=63519KB/s, maxb=63519KB/s, mint=66032msec, maxt=66032msec

随机读单进程
fio --name=RandRead1Process --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=0 --size=4G --numjobs=1 --group_reporting --filename=Rand1Process8G.testData
结果：
READ: io=4096.0MB, aggrb=22967KB/s, minb=22967KB/s, maxb=22967KB/s, mint=182616msec, maxt=182616msec


随机写 64 进程
fio --name=RandWrite64Process --ioengine=libaio --iodepth=1 --rw=randwrite --bs=4k --direct=0 --size=512M --numjobs=64 --group_reporting --filename=Rand64Process8G.testData
结果：
WRITE: io=32768MB, aggrb=1208.1MB/s, minb=1208.1MB/s, maxb=1208.1MB/s, mint=27106msec, maxt=27106msec

随机读 64 进程
fio --name=RandRead64Process --ioengine=libaio --iodepth=1 --rw=randread --bs=4k --direct=0 --size=512M --numjobs=64 --group_reporting --filename=Rand64Process8G.testData
结果：
READ: io=65536MB, aggrb=8381.7MB/s, minb=8381.7MB/s, maxb=8381.7MB/s, mint=7819msec, maxt=7819msec
```
线上业务再跑不好停机测试，只测了一遍，正常状态硬盘每秒最高能写入 120MB ， %util 不超过 30%

这 2 次出问题都是在晚上凌晨 2 、3 点，事发第一时间不能上去看，第二天上去看的时候除了硬盘写不动，一切跟往常没区别

线上数据库是 1 主 3 从，只有这一台塔式服务器出现过这种问题，另外 2 台卡片式服务器没问题，主库也是卡片式服务器也没问题，所以我现在想是不是这台塔式服务器的硬件问题

@Jeffrey4l 不是固定日期发生问题，2 次都是 MySQL 凌晨自动执行 optimize 出问题

@markgor 有告警的，但是 2 次事发的时候都是凌晨 2 、3 点，没能第一时间去看
这个服务器只有 MySQL ，UPS , node_exporter ，图形界面程序；只有 MySQL 主从同步进程写 IO
另外出问题的这台服务器是塔式的，其他卡片式服务器没问题，所以我在想是不是这台塔式服务器的硬件问题

卡片式（指机架式）服务器风道比较暴力，塔式服务器的风扇覆盖不一定全，可以看看磁盘 SMART 的运行温度。空调开着不等于硬盘的热量可以快速散掉。（南桥芯片同理。）

我在一台 ubuntu 16.04 有过相似情况
跑很多服务，有 redis 定时快照落盘写，60G/600sec
磁盘是 nvme ssd
跑了几年都没有问题
从某天开始
全系统落盘写 IO 100%，每秒只能写入 1X MB
重起系統可以暂时解决，不定期重现(数天)

检查过 CPU ，硬盘，网络，温度
也有 lsi 3XXX raid 卡
BUG 一但触发，只要涉及 IO 写，就会卡写 IO 100%，写入速度异常，影响所有盘写入(iotop)

几经搜索，怀疑是 kernal bug
参考其他人的做法，换 kernal 解决了问题
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1928744

最后也搞不明白为什么跑了几年才出问题

@masterjoess 我这台出故障的服务器 kernal 版本是 2.6 ，你的出问题的 kernal 是什么版本？升级到哪个版本解决了？
目前 2 次出问题都是操作了 MySQL optimize ，如果后续还出现这种情况考虑升级