这是一个创建于 195 天前的主题，其中的信息可能已经有所发展或是发生改变。
今早收到告警有一台物理机(RHEL7.5 && 3.10 内核)的/var 挂载点空间使用率超过 85%了，于是赶紧找哪个文件较大，发现了/var/cache/atop.d/atop.acct 这个文件占用了 41G （总 50G ），于是先查看了有没有进程打开这个文件，确定没有后，给这个文件挪到了其他挂载点，本以为磁盘空间会被释放，但并没有，df 看磁盘剩余空间没有变，被挪过去的那个挂载点磁盘使用空间倒是涨上来了。于是各种查 lsof 、fuser 啥的都查了个遍也没有啥发现。还有/var 挂载点的文件系统是 xfs （不知道有帮助没），请大家帮忙出出主意有啥好的方法排查吗？ reboot 比较难，上面业务很多
第 1 条附言 · 195 天前
兄弟们，冤枉啊，lsof |grep delete、lsof 文件、lsof +D目录都查过了，都没问题，没有进程打开
第 2 条附言 · 194 天前
兄弟们，今天早晨死马当活马医执行了一下 atop ，出结果之前卡了一会（ 20 多 s ），然后结果出来我就退了，神奇地发现了/var 磁盘使用率恢复了，/var/cache 下的 atop.d 的文件夹都没了，太奇怪了！
 |
1
yanqiyu 195 天前
确定检查方法对的？主要是有时候可能 lsof 里面的路径就不对/有些进程打开的文件只有 root 下才能看到
sudo lsof | egrep "deleted|COMMAND" 检查 DEVICE 号码和 SIZE 对的上的（不要只看路径，以及不要再非 root 下执行） 要是找不到另说，找到了就 echo > /proc/<pid>/fd/<fd> 释放空间 --- 其实对于这种文件空间爆炸，建议就 echo >/path/to/file 再删除，能保证释放空间而不用 lsof 到处找 |
 |
2
my3157 195 天前
truncate -s 0 <fp>
|
 |
3
seers 195 天前 via Android
句柄没释放
|
 |
4
pagxir 195 天前 via Android
也有可能被 mount 成回环磁盘了。
|
 |
5
zxf9799 195 天前  1
1 楼正解，这个在服务器上遇到很多次了，估计有啥进程永久占用这个文件了，句柄保存的情况下空间不会释放，lsof 命令看下这个文件是不是还在
|
 |
6
iphoneXr 195 天前
atop 命令执行完成之后就会后台继续运行的
你要用进程查看下 是否 atop 进程还存在？ 命令如下 ps aux|grep atop 杀完了 atop 进程再去用 ncdu 分析下磁盘大文件把。 |
|
7
iphoneXr 195 天前
帮人帮到底把。
执行这个应该就能释放空间 恢复正常了 ps aux|grep atop| grep -v grep | awk '{print $2}' | xargs --no-run-if-empty kill -9 |
 |
9
h2ero 195 天前
既然是 atop 的，就 kill 下 atop 得了
|
 |
10
zhoudaiyu OP |
Select Language