背景
最近一直收到产品环境其中一台server的磁盘占用超过90%的警告,之前为了解决这个问题编写了一个压缩和删除历史log的脚本,正常情况来说应该不会再报这个警告,因为脚本是每天都在跑,所以每天增长的log的大小应该不至于占用很多的磁盘空间,但是实际情况却是每隔两三天就会收到一次警告,然后不得不手动的清理一些还没有被脚本压缩以及删除的log,从而释放一些空间,但是这不是长久之计,所以就详细的去查了这个问题。
解决
再次受到这个警告之后,我通过SSH连到了这台机器,然后通过df -h的命令查看了一下各个挂载磁盘的使用率如下图:
从图中可以看到可以看到 /dev/xvdb1这个磁盘被挂载在/alidata1/这个目录下,并且已经使用了34G(90%).
然后就要查看/alidata1下到底是哪个文件或者文件夹占用了这么多的磁盘空间,我们通过du -h --max-depth=1来查看,如下图:
我们可以看到 /alidata1下的所有文件及文件夹占用的空间是22G,和我们通过df -h查看出来的磁盘占用34G相差12G,这是为什么?这12G的空间到底是被谁占用了?
于是去网上查了一些资料,原来是因为在Linux上删除一个进程正在写入的文件的时候,虽然已经被我们删除了,但是只要进程还在,那个文件就不会真正被删除,只是被临时存放到系统的某个地方,有点类似于Windows的回收站。通过lsof可以查看没有被真正删除的文件。如下图
从图中我们可以看出有四个占用空间比较大的没有被真正删除的文件,这四个文件分别是809和808的java进程console的输出log。之前被手动删除,但是由于没有重启进程导致文件一直还在,占用了大量空间。在通过重启808和809的java进程之后,磁盘的警告恢复了,通过df和du查看的结果如下:
df -h
从新的结果中可以看到df查看的磁盘占用空间和du查看的文件中下文件的占用空间一致了。
总结
所以如果以后碰到一些不合理的一些磁盘占用情况,我们可以通过df和du来查看磁盘占用空间和实际的文件占用空间是否有差异,如果有差异通过lsof命令查看有哪些没有被真正删除的文件,确认是被哪个进程占用,通过重启进程的方式来释放这些空间。
电脑出现这种情况,可以尝试以下方法解决:1、关闭家庭组,因为这功能会导致硬盘和CPU处于高负荷状态关闭方法:Win+C – 设置 – 更改电脑设置 – 家庭组 – 离开如果用不到家庭组可以直接把家庭组服务也给关闭了:控制面板 – 管理工具 – 服务 – HomeGroup Listener 和HomeGroup Provider 禁用。2、关闭磁盘碎片整理计划用好磁盘碎片整理可以提高磁盘性能,如果习惯手动整理,可以关闭整理计划,避免在你工作的时候自动整理,影响性能。资源管理器,选中磁盘 - 属性 – 工具 – 对驱动器进行优化和碎片整理 – 优化 – 更改设置 – 取消选择按计划运行。3、设置好 Superfetch 服务控制面板 – 管理工具 – 服务 – Superfetch - 启动类型 – 自动(延迟启动),可以避免刚启动好Win8对硬盘的频繁访问。欢迎分享,转载请注明来源:夏雨云
评论列表(0条)