共计 889 个字符，预计需要花费 3 分钟才能阅读完成。
项目中要改一下 Nginx 的配置，于是通过跳板机登录了 Nginx 机器。结果看到这个景象：
刺激，服务器空间没了，先解决一下这个问题吧，不然也没法写入，而且服务器也没法正常运行了。
分析：这台机器只负责运行 Nginx，空间占满很大程度上是因为日志生成太多。根据分析思路，我先去看一下磁盘空间的使用状况：
命令：df -h
确实有个使用率已经高达百分百的块，但是我对这一块不了解，不知道到底是哪一块这么满，于是到根目录下看一下到底是哪个目录这么大：
命令：du -sh /*
发现了，原来是 home，通过按照大小查看当前目录下所有文件进去，最后定位到 Nginx 目录：
指令：du -s * | sort -nr
确认 error.log 可以删除之后，删除文件：
指令：rm error.log (不要随便用 rm -rf)
结果发现，清理之后系统仍然提示空间不足，明明文件已经清楚，到底咋回事呢？我又看了一下，确认是否删除了正确的文件：
指令：du -sh * | sort -nr
可以看出，刚才占空间 59G 的 error 日志已经删除，但是还是空间不足。这时我想到，是不是因为 nginx 正在运行，这个 error.log 文件正在被占用，进行删除操作被存起来了，等待 nginx 进程结束之后才能删除。于是查看删除队列中的信息：
指令：lsof | grep deleted
果然不出所料，这些文件实际上还存在，所以接下来要暂时关闭一下 nginx 释放进程，好让系统执行这些删除任务，但是考虑到可能有人正在使用 nginx，为了影响最小化，于是使用响应速度更加快的 reopen 操作，重启 nginx（重启指令只有一条，等于 stop+start，执行起来肯定比手动输入 stop 然后再 start 要快，影响更小）：
指令：nginx -s reopen
重启的时候，明显感到卡顿了一下，看来是已经执行了删除任务，清理掉了 59G 的文件，检查一下：
指令：还是 lsof | grep deleted
可以看出，文件已经被清理掉了。
用 du 指令检查一下，可以看出 home 目录已经成功瘦身 59G，而且系统已经不提示空间已满了~：
总结：清理文件要注意，小心使用 rm -rf。清理之后仍没空，查看是否被占用。
