一次磁盘满的情况处理

收到系统磁盘满告警，查看告警机器，发现data目录已经满了：

[root@VM-41-182-Linuxos /data]# df -h

Filesystem Size Used Avail Use% Mounted on

devtmpfs 7.7G 0 7.7G 0% /dev

tmpfs 7.7G 16M 7.7G 1% /dev/shm

tmpfs 7.7G 266M 7.5G 4% /run

tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup

/dev/vda1 99G 11G 85G 11% /

/dev/vdb 296G 286G 0 100% /data

tmpfs 1.6G 0 1.6G 0% /run/user/0

data目录是我们通常用来运行服务的目录。

首先du分析一下/data目录，发现占用的并不大，才10来个G，而这里提示286G都被占用了。

这种时候，就要考虑一下是不是系统太久没有重启，比如这里的系统超过一年没有动过了，虽然有定时任务删除历史的log，但是打开的文件句柄在不重启的情况下依旧占用在内存中。

所以查询一下deleted的数量：

[root@VM-41-182-Linuxos /data]# lsof | grep '(deleted)' | wc -l

26290

数量还不少嘞。查看一下详情，到底是什么：

[root@VM-41-182-Linuxos /data]# lsof | grep '(deleted)'

... ...

sleep 3267 root 1w REG 253,1 5102 656494 /tmp/20230607C4JEsgenbONunroDKrGOhrGu/temp-output-run_tool_20230607C4JEsgenbONunroDKrGOhrGu_e0b79543fce9845a_tmp.sh (deleted)

sleep 3267 root 2w REG 253,1 5102 656494 /tmp/20230607C4JEsgenbONunroDKrGOhrGu/temp-output-run_tool_20230607C4JEsgenbONunroDKrGOhrGu_e0b79543fce9845a_tmp.sh (deleted)

uwsgi 3849 root 12w REG 253,16 0 11682305 /data/server/mirror/logs/actuator_server/actuator.log-2024-01-30 (deleted)

uwsgi 3849 root 13w REG 253,16 1231 11682306 /data/server/mirror/logs/actuator_server/debug.log (deleted)

uwsgi 3849 root 14w REG 253,16 0 11682307 /data/server/mirror/logs/actuator_server/error.log (deleted)

uwsgi 3849 root 15w REG 253,16 1231 11682308 /data/server/mirror/logs/actuator_server/info.log (deleted)

uwsgi 3867 root 12w REG 253,16 0 11682305 /data/server/mirror/logs/actuator_server/actuator.log-2024-01-30 (deleted)

uwsgi 3867 root 13w REG 253,16 1231 11682306 /data/server/mirror/logs/actuator_server/debug.log (deleted)

uwsgi 3867 root 14w REG 253,16 0 11682307 /data/server/mimirror/logs/actuator_server/error.log (deleted)

uwsgi 3867 root 15w REG 253,16 1231 11682308 /data/server/mirror/logs/actuator_server/info.log (deleted)

uwsgi 3867 3869 root 12w REG 253,16 0 11682305 /data/server/mirror/logs/actuator_server/actuator.log-2024-01-30 (deleted)

发现其中actuator_server这个服务占用量比较大，再查一下这个服务下deleted的文件有多少：

[root@VM-41-182-Linuxos /data]# lsof | grep '(deleted)' | grep 'actuator_server' | wc -l

25140

果然大部分都是ta的锅，直接删除：

[root@VM-41-182-Linuxos /data]# less z.txt | grep 'actuator_server' | awk '{print $2}' | xargs kill -9

不过，好像重新删除也没有效果。具体也没细究，线上环境直接重启actuator_server服务。

之后再次查看df，磁盘正常了：

[root@VM-41-182-Linuxos /data]# df -h

Filesystem Size Used Avail Use% Mounted on

devtmpfs 7.7G 0 7.7G 0% /dev

tmpfs 7.7G 15M 7.7G 1% /dev/shm

tmpfs 7.7G 266M 7.5G 4% /run

tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup

/dev/vda1 99G 11G 85G 11% /

/dev/vdb 296G 6.9G 274G 3% /data

tmpfs 1.6G 0 1.6G 0% /run/user/

在 Linux 系统中，当一个文件被删除（或者说被 unlink）时，如果还有进程持有该文件的句柄（也就是打开的文件描述符），那么这个文件的磁盘空间并不会立即被释放。这是因为在 Unix 和 Linux 中，删除一个文件实际上只是减少了文件名到文件内容的链接数量。只有当链接数量减少到零，并且没有任何进程打开该文件时，文件占用的磁盘空间才会被操作系统回收。

这种设计允许应用程序在不影响其他进程的情况下删除文件，同时还能继续使用已删除文件的内容。这在很多情况下都是非常有用的，例如，你可以在不中断服务的情况下升级正在运行的程序。

这里想说明的

1、当磁盘满了df查不出原因的时候，使用du可以进一步分析各个目录的占用情况

2、删除的文件句柄并不会立刻释放，当出现大量这种情况的时候，需要重启服务。