网上科普有关“kvmdiskio突然为0”话题很是火热，小编也是针对kvmdiskio突然为0寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助到您。
1、之前偶尔也会出现个别readonly的情况，没有深入排查，只是推测和chunkserver磁盘坏道有关，当vm读写正好在chunkserver坏道的块上时，可能出现报错，导致异常。
2、此次出现大批量readonly，且监控和日志显示均是在凌晨出现，故排除磁盘坏道问题。
3、如果虚拟机上承载docker 、mysql 等可能造成大并发的业务，也可能造成此类问题。但是虚拟机镜像在mfs上是连续的空间，正常的mysql读写并不会有问题。有出现在vm上进行批量docker容器删除时，出现异常的情况。
4、推测有vm用户提交了大量并发的读写任务，而我们并未对虚拟机读写进行限制，也有可能造成此类问题。前期有vm出现load 90+ 报警,紧接着就有chunkserver出现load 100+的报警，和此问题非常类似。
排查定位：
1、检查宿主机负载、网络等，未发现异常情况。
2、检查mfschunkserver ，发现有部分磁盘出现raid errro。
3、检查mfschunkserver ，发现有一台chunkserver出现load +100，iowait达到90%以上的情况，带宽未见异常，写入的数据量也很低，现象大概持续3分钟左右。
4、检查vm在凌晨的监控情况，发现批量机器出现iowait达到100%，流量、load均未见明显异常。有部分vm上有大量的sendmail进程。
5、检查虚拟机上凌晨的crontab、进程等，没有发现异常。
6、检查mfs上的读写情况，未见在凌晨有大量的 chunk create 和replica，但是 max operations in queue 值特别高。
7、检查虚拟机备份程序，发现正好是在凌晨0:10进行备份，执行了snapshot操作，而且每台vm备份间隔仅1s，初步确认此备份为导致异常的主要原因。
由于snapshot操作并未带来大量的读写，之前并未关注到。在深入剖析了snapshot的原理，发现是执行了类似linux 系统的硬链接操作，此时批量的snapshot虚拟机，200台vm大概20TB，按照mfs的每个chunk块 64MB的划分，换算下来执行一次操作，会产生 2010241024/64 = 327680 创建链接的操作，每台vm备份也会产生1600次操作，如果在1s内没有完成，那么cpu队列就会越来越大，从而产生了load和iowait都非常高的现象。由于镜像备份并不是十分紧急的任务，故将间隔时间修改到60s执行一台。
可能造成虚拟机readonly故障的原因：
1、虚拟机备份进程的批量操作产生大量的并发，导致chunkserver 的cpu队列拥塞，产生vm读写出现iowait过高超时的情况，从而造成了磁盘remount为readonly的情况。故有此类批量操作的动作，一定要考虑并发负载的问题。 因为chunkserver是存储型服务器，cpu配置都比较低。
2、个别vm用户大量的提交任务导致后端异常。针对此现象，使用cgroug 进行io限制。可避免此类问题发生。
3、mfschunkser 规格建议配置一致，避免读写负载出现不均衡的情况。
此次定位问题耗时一周：
1、监控不到位，由于zabbix 进行大批量机器对比时，效率很低，临时部署了openfalcon和grafana，耗时较长。
2、没有关注到备份任务，之前一致以为是vm用户的问题，但是通过监控定位并不是用户的问题。
3、对mfs的snapshot未深入理解。
关于“kvmdiskio突然为0”这个话题的介绍，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！
本文来自作者[之亦]投稿，不代表长隆号立场，如若转载，请注明出处：https://clcgzw.com/cshi/202502-1046.html
评论列表（4条）
我是长隆号的签约作者“之亦”！
希望本篇文章《kvmdiskio突然为0》能对你有所帮助！
本站[长隆号]内容主要涵盖：国足,欧洲杯,世界杯,篮球,欧冠,亚冠,英超,足球,综合体育
本文概览：网上科普有关“kvmdiskio突然为0”话题很是火热，小编也是针对kvmdiskio突然为0寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题，希望能够帮助...