从磁盘满聊技术问题如何问、去哪问
潘忠显 / 2023-11-20
我有一个开发环境的 CVM,近期系统盘满。本篇小文从这个 VM 系统盘满的问题开始,通过介绍解决过程,少聊技术,多聊聊如何提问、去哪问、如何提高生产力,以及少少感触。
一、逃避问题还是解决问题
我申请的 CVM 的规格是16核/32G内存/100G系统盘/500G数据盘。其实最近半年,这个 CVM 都会经常比较满,具体的就是 df -h
会看到磁盘利用率超过 90% 甚至达到 100%。
我的解决方法就是 du -sh
看看什么文件比较大,然后清理一下。因为我用 CVM 主要是用于构建,所以构建相关的文件会比较多:
- Docker 拉取的镜像,可以使用
docker system prune -a
清理掉 - Bazel/Go/Sbt 等的 Cache 目录
- /var/log/messages-* 里边的日志
但是,清理 Cache 的动作甚至都不能算个 WorkAround,再次拉取或者构建总会再填回来,治标不治本。
问题大到一定程度,逃避问题不是办法,解决掉它才能解放自己。
我就直接 du -sh *
一下看看具体哪个文件大,虽然有大文件,但自己算了算加起来也没有 df
显示的 100G 呀(实际使用只有不到 50G)。
术业有专攻,去找运维同学咨询一下会有什么可能造成这种情况。
运维同学提供的思路是,可能有 deleted
文件没有被释放:之前我也碰到过这种,删掉了大日志文件,但是有进程打开了这个文件但没有关闭,就不会释放空间。为了简单处理,直接重启了系统,现象依旧。
于是决定去外部再问问,走,Stack Overflow。
二、被关闭的“坏问题”
整理一下已经做过的排查步骤和结果,在 Stack Overflow 进行提问,主要是列上:
df -h
的结果du -sh / --exclude=/data --exclude=/proc
的结果lsof | grep delete
结果为空ls .[^.]*
没有隐藏文件free -h
没有设置 swap 空间
贴在 Stack Overflow 上,没有多久就有反应了。只不过是 Down Vote,伴随着 Close 的投票。又一个,又一个。
Stack Overflow 有两个规则这里提一下:
- Close 投票达到了3,问题会被关闭,别人就不能回答了
- 1个Down Vote会减 2 Reputation
- 删掉问题或回答,减的 Reputation 会恢复,但是问题就不可见了
问题被强制关闭了,而我还在觉着这个问题比较明确、详实。不能一删了之,因为那样既得不到问题的答案,最终也没搞清楚Stack Overflow的规则。
因此,我仔细看了一下被大家投票关闭的原因:大概的意思是说,这个问题不是关于编程或软件开发的(与特定的编程问题、软件算法或程序员主要使用的软件工具无关)。同时,他也提示可以去 on-topic 或者去其他 Stack Exchange 网站试试。
Closed. This question is not about programming or software development. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. You can edit the question so it’s on-topic or see if it can be answered on another Stack Exchange site, but be sure to read the on-topic page for a site before posting there.
通过这些提示,在回忆一下之前在 Stack Overflow 上回答的问题确实都是关于特定编程语言的问题,以及搜索 Linux 问题确实大都被引导到 unix.stackexchange.com 上了。
三、Stack Exchange是什么
上边的提示中,说让去"another Stack Exchange site"问问。这句话有两个含义:
- Stack Overflow 属于 Stack Exchange site
- Stack Exchange 还有其他类似于 Stack Overflow 的网站
直接看看 stackexchange.com/sites 的面板,可以看到我们常用的一些网站,比如 Server Fault、Super User、Ask Ubuntu、Unix&Linux、Mathematics,都属于 Stack Exchange:
WikiPedia上介绍:Stack Exchange是一个由问答 (Q&A) 网站组成的网络,涉及不同领域的主题,每个网站都涵盖一个特定主题,其中问题、答案和用户都受到声誉奖励流程的约束。
Stack Exchange 自己的 About上介绍:Stack Overflow 和 Stack Exchange 网络可帮助人们在需要时找到所需的答案。 由包括 Stack Overflow 在内的 173 个问答社区组成,每月有超过 1 亿人访问提问、学习和分享技术知识。
四、问题得放对位置,人也一样
经过 Stack Overflow 的打击和提示,我弄懂了它和 Stack Exchange 的关系,不是所有的问题都可以放在 Stack Overflow 的——怎样,果然是个“老白码农在奋斗”吧?
于是,我将问题直接复制了一下,贴在了 Unix&Linux 上。反应一样很快,很快有了 Comment,甚至还有两个 Up Vote:
经过几个人的提示,我使用了 fsck
去检查了文件系统是否有问题。具体地使用 fsck -nf /dev/vda1 > fsck.log
将检查结果放到文件中,然后分析发现确实有很多文件系统问题:
- 10 个 Deleted inode N has zero dtime
- 7 个 Free blocks count wrong for group
- 1 个 Free blocks count wrong
- 17 个 Directories count wrong for group
- 1 个 Free inodes count wrong
然后尝试使用 fsck -a
来尝试修复,但是因为是被 mount
了,所以不能被修复。使用 fsck
修复文件系统的正常操作应该是先 umount 设备,然后再修复,最后再 mount 上。这种 CVM 不像我们手头的机器,可以用 live CD 登录,然后操作修复。所以这里只能找提供 CVM 的云产品的同学去处理。
这里让我有第1点感触:同样的一个问题,贴错了地方,被人 Down Vote 2下并关闭,贴对了地方被 Up Vote 两次,并基本顺利地排查到了根本问题。
打工人又何尝不是这样?把自己放错了地方,再怎么努力也可能背星;放对了地方,游刃有余又容易有产出。不管是主动还是被动地换位置,换对位置才能有好结果。
五、细思极恐的上帝视角
在 Stack Exchange 搞清楚原因之后,直接联系了云的同学,他们也是提示让 lsof、重启看看是否有变化。
我这边重点提示了**“是不是应该从VM的Host上去修复”**之后, 云同学说关机修复一下,过了段时间让我登入一下试试,果然问题解决了。
我确认了一下云同学的操作,他们说**“就是fsck修了下而已”**。
这里让我有第2点感触:在一些层次遇到无论如何都无法克服的 Bug,从更高的视角来看,也仅仅是个“小问题而已”。
生活亦是如此,如果遇到什么过不去的坎,付出那么多的努力都没用。请不要气馁和放弃,可能就是上帝视角不小心弄错了一个什么小问题,等他轻轻修复一下,可能一切都会顺畅无比。
六、先问 ChatGPT
其实最近已经养成习惯,遇到的问题去问 ChatGPT,但是这次觉着这个问题可能是常见运维问题,所以直接请教专家。
而当我解决完问题,再回头尝试问问 Chat GPT 的时候,发现可能不用请教运维同学,也不用上 Stack Exchange 就能直接找出原因。
不要排斥新技术,积极地去接受和利用新技术,才能更高效的工作,才更有可能早一天成为 wlbcoder。
这包括但不限于使用 ChatGPT 和 Copilot。一位使用 Copilot 的同事说,“没有 Copilot 的就像原始人”。积极地去尝试,尽早感受到跨越式的生产力提高。