寻找原因

从字面上理解,这个问题是说磁盘上没有多余的空间

那么到底是什么地方将空间?

  1. 先用df命令查看当前计算器磁盘空闲情况
df -a

我这边执行完后可以看到/dev/vda1被完全占用

  1. 从根目录下开始使用du命令查找出空间占用最大的文件
#查看当前目录下每个文件夹所占用的空间
du -sh *

通过一层一层的比较文件所占用空间,发现是jenkins的运行日志文件占用最大,本来我这边的的服务器磁盘仅100G,结果这个日志文件就有86G,我明白就是这个文件将磁盘占满了

解决方案

我首先想到的是直接删除该文件,于是我进入到jenkins的目录下,直接删除了所有日志。

rm -rf *.log

命令执行后,服务器的其他程序临时可以正常使用了。但是我运行df命令时发现/dev/vda1还是被完全占用,但是我想应用都正常在运行了,那也许是系统需要重启或过一段时间才能更新该状态,我也就没有再理会这个问题。

然而,这个问题并没有就此结束。第二天同事发现应用又不能访问了,我意识到昨天的那个问题还没有结束。我再次执行了dfdu命令,发现df的结果中表明/dev/vda1依然被全部占用,而du的结果中却没有再发现大文件了。我尝试着将解决这两种结果不一致的问题,兴许解决后就能解决”No space left o device”的问题了。

根据两个命令结果,我猜测应该是昨天直接通过rm命令删除的文件空间没有被释放,所以我查看了系统中所有被打开的文件,在其中寻找到了那个日志文件”jenkins.log”。

lsof | grep "jenkins.log"

列表中有很多进程都在打开该文件,虽然文件删除了,但是打开该文件的进程没有关闭,也就是说文件实际上还是存在,rm仅仅是删除了该文件的标记

于是乎我果断的终止了打开该文件的进程。

kill -9 22731

执行完毕后,再次运行dfdu,发现结果相差不大了。到此系统又可以正常运行了。

虽然这个问题算是临时解决了,但是jenkins的日志为什么可以达到86G?这个问题还没有得到解决,由于这一次删除的的充满,没有仔细看看日志的内容,导致该问题的原因不太能够查出。但是这个问题的根源肯定是没有被解决的,只能等到下一次该问题出现后,好好研究一下该日志,从根本上解决这个问题。

相关资料

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐