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