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