新股停牌规则:生产事故磁盘使用率爆仓

2021-03-31 21:07:18 来源： 浏览：1次

    生产事故磁盘使用率爆仓
    
     收录于话题
    
    哈喽哈喽大家猴，我是把代码写成bug的大头菜。公众号：大头菜技术(bigheadit)。原创不易，但欢迎转载。
    今天不知道为啥醒得特别早，可能就是缘分吧。醒来一看微信，就发现线上的服务器的磁盘使用率超过70%，真是早起的鸟儿有bug修。。。。。
    磁盘使用率1当时我就立马跑去看看监控，看看cpu,内存,io这些是否都正常。看了一圈，发现除了磁盘异常外，其他一切都正常。
    我当时是7点左右看到的消息，看到后，磁盘的使用率达到72%，超过了设定阈值70%。就如上图的红色箭头所示。
    当时我是直接进入服务器，用df -h查看服务器的磁盘使用空间。
    看到上图，当时我人都傻了。2.7T空间，然后使用才5%，哪来的70%磁盘使用率。
    后来深呼吸，喝口冰水冷静一下，发现，公司用的是容器，而df -h查的是物理服务器的磁盘空间。当时我情况比较紧急，我也忘了什么命令可以查容器的硬盘空间。只好去谷歌输入框输入：“如何查看容器的磁盘空间”
    很快，我就搜到相关命令：docker system df -v
    然而，等待我的却是
    dockersystemdf-v
    -bash:docker:commandnotfound
    我太难了牛逼！！！牛逼！！！
    好吧，看来是没办法通过命令查看哪个地方用的磁盘空间比较大了。不过又比较紧急，只能用最笨的方法：遍历查询。但是这个遍历，我优先遍历查看日志文件。没想到一击即中，立马就找到了磁盘爆满的根本原因。
    你看，从2月25号日志到现在3.21号的日志都在，总共占用了20G。我问了运维每台容器分配30G。20G/30G=66.7%。单纯日志已经占用磁盘空间的66.7%，再加上其他的应用，占用70+%。实锤了，找到真凶了。我也没想到这么快找到。
    至于为什么我一开始就找日志文件呢？主要是因为经验吧，因为之前别的服务器也出现过磁盘使用率问题，当时也是因为日志文件问题。简单总结一下，虽然经验不总是可靠，但排查线上问题时，经验又总是那么有用。因此，排查问题时，一开始要根据监控数据，进行排查，不要先入为主，用想当然去排查，就是不用经验去想问题。先跳出固有圈子，根据实实在在的监控指标数据排查。实在没办法时，再用经验去排查也不迟。
    那么现在我们已经定位到磁盘空间问题的根本原因：日志文件占用空间过多。
    那接下来应该怎么做呢？
    只能删文件，腾出空间。遇到磁盘使用率问题，除了删文件，还有其他办法吗？有，扩大磁盘空间，但多大才够，这方案显然不是最高效的解决方案
    这时候终于可以搬出好久没使用的：rm -rf命令了。
    嘿嘿一笑很倾城我当时就直接把2月份的日志都删除了。
    立马看一下监控图
    磁盘使用率立马断崖式下降到70%以下，首要任务让服务器正常运行再说。
    到这里后，你以为就结束了吗？。。。。。。。并没有
    交代一下服务器的背景：四台服务器，每台服务器2核8G。
    删文件前：删文件后：我们可以看到，删文件的操作，的确暂时让磁盘的使用率从71%降到63%。但是，你发现没发现另一个问题。
    另外2台服务器的磁盘使用率只有1%。但是另外2台的服务器的日志文件都占了大约20G（容器的硬盘空间30G）
    这让我再一次傻眼儿了！！！！
    明明大家都占用了20G，2台服务器70%的使用率，另外2台服务器的使用率却高达1%。
    amazing!!!!!
    害，母鸡道点算(粤语)！！！
    当时心想，先不管了。服务器现在也正常服务了，等上班后，再和运维聊聊，找找原因。毕竟现在才7点，离上班还有3个小时。没法找运维的！！！
    带着满怀激动的心情，终于等到10点上班了。
    经过和运维的一番描述(battle)后，终于找到了答案，解开了疑惑。
    其实，就是监控数据的获取有bug，从而导致数据不准确。
    最后我还抓着运维，问了一下如何查看容器的硬盘使用空间？
    然而。。。。他好像也不太会。。。。
    好了，今天的bug顺利解决了。就是查看容器的命令，到现在也没找到。如果你有办法，留言通知我！感谢！
    推荐阅读《技术周报》20210322-20210326
    用泊松分布来解释为什么HashMap的链表变树的阈值是8
    双亲委派模型
    

上一篇：没有了
下一篇：宋冬野老婆:港股打新基本术语(发售招股阶段)