服务器磁盘突然写入巨慢问题 - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要在回答技术问题时复制粘贴 AI 生成的内容
AnjingJingan
V2EX    程序员

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

  •  
  •   AnjingJingan 2022-05-03 16:56:16 +08:00 3992 次点击
    这是一个创建于 1266 天前的主题,其中的信息可能已经有所发展或是发生改变。

    问题现象

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

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

    磁盘写不动 OkgvD0.png

    从凌晨 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 也不知道用什么关键词?

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

    18 条回复    2022-05-06 17:24:57 +08:00
    neutrinos
        1
    neutrinos  
       2022-05-03 17:03:06 +08:00 via iPhone   2
    关机十分钟后才能缓解的影响因素我只能想到是温度
    markgor
        2
    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
        3
    AnjingJingan  
    OP
       2022-05-03 17:24:39 +08:00
    @markgor 感觉还是不太一样,我这边的情况 cpu 是正常的,并且 optimize 早就执行完了,不是 optimize 过程中出现的
    比如这次出现的问题,5 月 1 号 晚上执行的 optimize ,到今天 3 号磁盘都还是写不动,optimize 肯定是早执行完了
    AnjingJingan
        4
    AnjingJingan  
    OP
       2022-05-03 17:27:20 +08:00
    @neutrinos 10 平米的机房 2 台空调 24 小时开着,温度应该没问题
    documentzhangx66
        5
    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
        6
    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
        7
    id4alex  
       2022-05-03 18:07:41 +08:00
    碎片整理是这样的。
    documentzhangx66
        8
    documentzhangx66  
       2022-05-03 18:39:34 +08:00
    另外温度的确要检测一下,各物理磁盘温度,各 CPU 温度,主板温度,等等。打上时间戳,放入运维系统。

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

    所以等待十分钟可能是不必要的,可能只是需要关机断电再开机通电。复现问题,关机再开机,如果立即恢复了就可以排除温度过高的可能
    bg7lgb
        11
    bg7lgb  
       2022-05-03 21:15:13 +08:00
    raid5 写性能很差,数据库要 IO 还是得上 Raid10 。
    Jeffrey4l
        12
    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
        13
    AnjingJingan  
    OP
       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
        14
    AnjingJingan  
    OP
       2022-05-04 10:54:28 +08:00
    @Jeffrey4l 不是固定日期发生问题,2 次都是 MySQL 凌晨自动执行 optimize 出问题
    AnjingJingan
        15
    AnjingJingan  
    OP
       2022-05-04 11:01:50 +08:00
    @markgor 有告警的,但是 2 次事发的时候都是凌晨 2 、3 点,没能第一时间去看
    这个服务器只有 MySQL ,UPS , node_exporter ,图形界面程序;只有 MySQL 主从同步进程写 IO
    另外出问题的这台服务器是塔式的,其他卡片式服务器没问题,所以我在想是不是这台塔式服务器的硬件问题
    msg7086
        16
    msg7086  
       2022-05-04 14:17:26 +08:00
    卡片式(指机架式)服务器风道比较暴力,塔式服务器的风扇覆盖不一定全,可以看看磁盘 SMART 的运行温度。空调开着不等于硬盘的热量可以快速散掉。(南桥芯片同理。)
    masterjoess
        17
    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
        18
    AnjingJingan  
    OP
       2022-05-06 17:24:57 +08:00
    @masterjoess 我这台出故障的服务器 kernal 版本是 2.6 ,你的出问题的 kernal 是什么版本?升级到哪个版本解决了?
    目前 2 次出问题都是操作了 MySQL optimize ,如果后续还出现这种情况考虑升级
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     5315 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 51ms UTC 07:18 PVG 15:18 LAX 00:18 JFK 03:18
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86