大家比拟经常出现的状况应该是内存或许 CPU 的告警，磁盘相对来说不那么容易出疑问，毕竟大局部运行都不须要和磁盘交互，磁盘告警的示例如下：
普通遇到磁盘爆满的告警，第一步要做的就是确认告警消息能否正确，登录主机，经过 df -Hl 检查：
可以看到 /dev/vda1 占据了 43G 的内存，和告警消息分歧，接着我们就是要找到造成磁盘空间满的详细目录或文件。
如何定位占用少量磁盘空间的目录或文件？
一种基础的做法是，在根目录下口头du -hs命令，列出各个目录的大小。
为了进一步细化，可以进入详细的目录重复该操作。这种方法只管便捷，但不够高效。
更优的方法是经常使用du命令的-d参数（或--max-depth参数），设置目录扫描的深度。扫描深度越大，输入的结果会越多，此时可以经过grep过滤不用要的消息。
du h d grep GT sort nrdu h 这种形式可以极速挑选出以G或T为单位的大目录，并按大小排序。
另一种更高效的方法是经常使用find命令：
find / -type f -size +1G -exec du -h {} \;相较于du，find愈加灵敏和极速。经过这两种形式，可以迅速定位占用磁盘空间的文件或目录。
磁盘空间不分歧的状况
但是，事件并不总是这么便捷。有时你或许会发现，经常使用find或du查找到的文件占用空间与df命令显示的磁盘经常使用量相差甚远。比如上图我们经常使用du -hs检查根目录下一切文件的总和就只要10G左右，但 df显示磁盘占用了37G，没有暗藏目录的状况下，残余的空间去了哪里？
这种现象通常是由被删除的文件占用空间但未监禁资源造成的。只管文件被删除了，但系统还没有真正监禁其占用的空间。
此时，我们可以经常使用lsof命令来审核能否有未齐全监禁的文件：
从上图结果中可以看到，有一个被删除但仍占用约28G空间的日志文件。这是比拟经常出现的状况。处置方法是重启关系运行（如Tomcat），以监禁这些被占用的空间。
磁盘空间被系统保管
有时刻，你或许还会发现df命令显示的Used和Available空间之和小于Total大小，仿佛有局部空间"隐没"了。
这实践上是Linux文件系统的安保机制。自动状况下，系统会为root用户预留5%的磁盘空间，用于紧急状况。这样可以确保关键运行（如数据库）在磁盘满时仍有大批空间，防止解体。
假设须要监禁这局部保管空间，可以经常使用tune2fs命令调整预留空间的比例：
tune2fs m devvda1上述命令口头后将只保管 1G 的安保空间：