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

2022-05-03 16:56:16 +08:00
 AnjingJingan

问题现象

生产环境有个 mysql 从库服务器,只装了 mysql ,出现了 2 次磁盘写入巨慢的情况

先看图,磁盘正常写入速度

磁盘写不动

从凌晨 3 点开始,磁盘突然写不动,并且 IO 耗时巨高,每秒只能写入 1 、2 MB

与之带来的问题是 MySQL 主从延迟越来越高

出问题的 2 次都是在夜间自动执行了 MySQL 表优化,就是这个语句

optimize table `table_name`;

表引擎是 MyISAM ,并且都是大表,一张表 索引长度+数据长度 超过 50G

解决过程

第一次出问题搞了一整天,因为这台服务器只装了 MySQL 服务,也没有其他进程。

/var/log/messages 也没有发现异常

MySQL 错误日志也没发现异常

服务器系统环境是 centos6.5 , 4 块物理盘做的 raid5 阵列

首先是重启 MySQL ,磁盘写入依然慢

重启系统,没用

各种 百度 Google 都没发现有效线索

一度认为是物理磁盘坏了,但是磁盘是在线状态

最后关机,进入 bios 查看硬盘状态,没有做任何操作,开机后磁盘写入速度恢复正常了

这时候我怀疑是关机了一段时间后在开机,磁盘写入才恢复,但是不确定

第二次出问题后,先关机了 10 分钟,10 分钟后开机磁盘写入速度恢复正常

这时候可以确定要先关机一段时间,磁盘才能恢复正常,重启无效

疑问

虽然磁盘写入速度恢复了,但是问题点还是没找到,为什么磁盘会突然写不动?

如果是因为 optimize table table_name; 这个语句操作了大表,但是另外 2 个从库服务器没这种情况

最诡异的是重启无效,要关机一段时间再开机才能恢复

这种情况 Google 也不知道用什么关键词?

有大佬遇到过这种情况,或者知道是什么原因么?

3458 次点击
所在节点    程序员
18 条回复
neutrinos
2022-05-03 17:03:06 +08:00
关机十分钟后才能缓解的影响因素我只能想到是温度
markgor
2022-05-03 17:03:14 +08:00
有,但不是大佬,也不是 MyISAM 。
线上业务,单表 20 多 G ,删除 5GB 左右的数据,3 个小时,症状:
查询正常(大部分走从机)写入延迟 2~3 秒。
主机监控 CPU 狂飙,IO 使用率狂飙。
执行完后从机重复上面症状,并且主从同步延时拉扯到 13 秒。
等从机执行完后手动 alert 了一下表触发 optimize 操作。
大概 30 分钟,监控看到的是 CPU 和磁盘使用率一直升。
后来经过百度查询到由于 optimize 的时候 mysql 是创建一份新的数据,再物理删除旧的数据。
AnjingJingan
2022-05-03 17:24:39 +08:00
@markgor 感觉还是不太一样,我这边的情况 cpu 是正常的,并且 optimize 早就执行完了,不是 optimize 过程中出现的
比如这次出现的问题,5 月 1 号 晚上执行的 optimize ,到今天 3 号磁盘都还是写不动,optimize 肯定是早执行完了
AnjingJingan
2022-05-03 17:27:20 +08:00
@neutrinos 10 平米的机房 2 台空调 24 小时开着,温度应该没问题
documentzhangx66
2022-05-03 17:53:31 +08:00
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 ,看它到底在干啥。
markgor
2022-05-03 17:54:52 +08:00
@AnjingJingan #3 又重新认证看了下监控图,
每次写入慢=IO 100%
我觉得排障的流程应该变为:
IO 写入慢----此刻发生了什么事?是哪个进程 IO 导致 100%?
如果日志看不出来,建议可以设定监控,IO 持续 2 分钟 90%以上告警,然后远程进入看哪进程导致的。
另外可以看看 raid 卡日志,看看那个时间有没异常。

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

1 、增加硬件温度监控;--先确定是否硬件问题
2 、做好告警,触发时候第一时间去“现场”查看凶手
id4alex
2022-05-03 18:07:41 +08:00
碎片整理是这样的。
documentzhangx66
2022-05-03 18:39:34 +08:00
另外温度的确要检测一下,各物理磁盘温度,各 CPU 温度,主板温度,等等。打上时间戳,放入运维系统。

当出现问题时,看看各设备的温度。
felixcode
2022-05-03 18:54:51 +08:00
先看 IO 延时,高的话,看是 IOPS 高还是吞吐量高,要都不高的话可能是硬件问题,要有一项高的话就 iotop,strace 什么的寻找占用高的进程。
eason1874
2022-05-03 18:58:54 +08:00
重启跟关机再开机有区别,重启是不断电的,会跳过不少硬件检查程序

所以等待十分钟可能是不必要的,可能只是需要关机断电再开机通电。复现问题,关机再开机,如果立即恢复了就可以排除温度过高的可能
bg7lgb
2022-05-03 21:15:13 +08:00
raid5 写性能很差,数据库要 IO 还是得上 Raid10 。
Jeffrey4l
2022-05-03 21:48:24 +08:00
* 是固定日期发生问题么? 查下是不是 raid 的 Consistency Check 搞的鬼 https://www.gillware.com/raid-data-recovery/common-raid-performance-killers-consistency-checks/
AnjingJingan
2022-05-04 10:53:25 +08:00
@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 台卡片式服务器没问题,主库也是卡片式服务器也没问题,所以我现在想是不是这台塔式服务器的硬件问题
AnjingJingan
2022-05-04 10:54:28 +08:00
@Jeffrey4l 不是固定日期发生问题,2 次都是 MySQL 凌晨自动执行 optimize 出问题
AnjingJingan
2022-05-04 11:01:50 +08:00
@markgor 有告警的,但是 2 次事发的时候都是凌晨 2 、3 点,没能第一时间去看
这个服务器只有 MySQL ,UPS , node_exporter ,图形界面程序;只有 MySQL 主从同步进程写 IO
另外出问题的这台服务器是塔式的,其他卡片式服务器没问题,所以我在想是不是这台塔式服务器的硬件问题
msg7086
2022-05-04 14:17:26 +08:00
卡片式(指机架式)服务器风道比较暴力,塔式服务器的风扇覆盖不一定全,可以看看磁盘 SMART 的运行温度。空调开着不等于硬盘的热量可以快速散掉。(南桥芯片同理。)
masterjoess
2022-05-05 11:02:58 +08:00
我在一台 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

最后也搞不明白为什么跑了几年才出问题
AnjingJingan
2022-05-06 17:24:57 +08:00
@masterjoess 我这台出故障的服务器 kernal 版本是 2.6 ,你的出问题的 kernal 是什么版本?升级到哪个版本解决了?
目前 2 次出问题都是操作了 MySQL optimize ,如果后续还出现这种情况考虑升级

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/850652

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX