记录一次磁盘爆满问题引发的思考

记录一次磁盘爆满问题,引发的思考

事情是这样的，这是一个阳光明媚的上午，我还是和往常一样改代码，然后发版，但是今天项目放公司服务器上启动的时候出现了一点小问题。看下面的报错。

🤕看报错是因为，服务器可用磁盘只有2.6%了，超过了es的警戒线，导致所有的es索引都变成了只读状态，最终导致的启动失败。

那么现在问题就定位到磁盘空间占用了，使用df -h命令可以看到，磁盘已经使用99%了，已经使用掉3.5T大小了（因为这图是之后截的，实际上出问题的时候是98%）。

但是使用du -sh /data命令，来观察，发现服务器的**/data目录下才占用1.5T**，百思不得其解啊，于是就去各个目录挨个du看看(瞎转悠)。

一个上午过去之后冷静下来了，想了想会不会是以前删除过的东西没有完全删除掉，还是说du和df统计空间的机制不一样，然后去搜了搜。

还真是。。。。。。

使用rm命令删除的文件，并不一定会完全在磁盘中被释放，如果这个文件没有被任何进程所引用的话，那么rm之后，这个文件就被完全的从磁盘中释放出来了，但是如果还有进程去引用这个文件，再使用rm去删除，这个时候文件仅仅是在文件系统中看不到，实际还在占用着，要等到引用他的进程结束之后，才可以释放出空间，那么问题来了，我这是服务器啊，服务器不死，进程不死😦。

这种情况下可以使用lsof | grep deleted命令来查看，哪些文件被rm删除了，但是还在被进程占用，如下(公司服务器不好截图，我就用自己服务器啦)。

得知了这些之后整个事件就明朗了，使用df命令统计的磁盘空间会更加多一些，因为它会统计到那些被rm删除但是没有完全从磁盘中释放的文件，du命令则不会统计这部分被rm删除过的文件，因此，就导致了df -h统计出的磁盘空间占用远大于du统计出来的占用。

将对应的进程确认可以重启的重启一下，或者将服务器重启一下，问题就解决了。