解决Centos服务器/dev/mapper/cl-root或overlay挂载点/根目录磁盘内存满占用率持续高与实际磁盘内存不相符

问题描述：

在开发过程中,发现网页突然开不了,突然断线,诡异的断开又重连.终端连接服务器后,通过输入
df -h


[root@ackh-office-srv ~]# df -h
文件系统             容量  已用  可用 已用% 挂载点
/dev/mapper/cl-root   50G   50G  683M   99% /
devtmpfs              48G     0   48G    0% /dev
tmpfs                 48G   84K   48G    1% /dev/shm
tmpfs                 48G   98M   48G    1% /run
tmpfs                 48G     0   48G    0% /sys/fs/cgroup
/dev/md126p2        1021M  176M  846M   18% /boot
/dev/mapper/cl-home  5.2T  1.3T  3.9T   25% /home
tmpfs                9.5G  4.0K  9.5G    1% /run/user/0
tmpfs                9.5G   16K  9.5G    1% /run/user/42
overlay               50G   50G  683M   99% /var/lib/docker/overlay2/7388d1c81c4cd4a42b629d9a1f156c022474444436c4683396d8b2d6ed0436c2/merged
shm                   64M     0   64M    0% /var/lib/docker/containers/1cd6335f1b67041fcd4a43617288cfd9fd0c534b0066de2156eadda00d433bb5/shm
overlay               50G   50G  683M   99% /var/lib/docker/overlay2/883ab66c0922719519e6a17e409428e703b009cd4e2f6566ac1a9fb480eed671/merged
shm                   64M     0   64M    0% /var/lib/docker/containers/00da0f419c08f9163ead3ad8b29f964a9679996dc3d9453a41679c05eb8b9840/shm
overlay               50G   50G  683M   99% /var/lib/docker/overlay2/b51eb5f1f20b4636693e590af65c9187a55ad6ea5485bfc88b49af1f2e9e8577/merged
shm                   64M  8.0K   64M    1% /var/lib/docker/containers/9306555ac084a7fa5529c2216d906543db215d910ca74715b8ebb61c7d19bac1/shm
overlay               50G   50G  683M   99% /var/lib/docker/overlay2/8cf90078979cbf73dc6d21f47a57af9dc80e4ce4461898ad2d70870667d58615/merged
shm                   64M     0   64M    0% /var/lib/docker/containers/10d1a1ea1506619a1b27305e5c6a709f389a8a5cf3dac69d7288472a2bec7e07/shm

通过上图可观察,挂载根目录的/dev/mapper/cl-root 和overlay特别占磁盘.

我发现磁盘空间不足后，刚开始的思路是到/下通过du -sh 来查找大文件

cd / 　　　　　　　　　　　　　　　　　　　　　　　　　　　　//切换根目录
du -sh *　　　　　　　　　　　　　　　　//在根目录底下搜寻大文件

[root@ackh-office-srv /]# du -sh *
0 1
0 bin
143M boot
84K dev
148K dump.rdb
50M etc
1.3T home
0 lib
0 lib64
0 media
0 mnt
3.5G opt
du: 无法访问"proc/870/task/870/fd/4": 没有那个文件或目录
du: 无法访问"proc/870/task/870/fdinfo/4": 没有那个文件或目录
du: 无法访问"proc/870/fd/4": 没有那个文件或目录
du: 无法访问"proc/870/fdinfo/4": 没有那个文件或目录
0 proc
2.1G root
du: 无法访问"run/user/42/gvfs": 权限不够
98M run
0 sbin
0 srv
4.0K stop.sh
0 sys
2.7M tmp
7.4G usr
21G var

红色是挂载nfs的也就是挂载根目录的var(docker)和usr和opt最多就30G,咋占了50G.发现当前系统任然存在大量可以使用的空间。大量剩余的磁盘空间不清楚怎么丢失了…

如果发现是因为磁盘目录满了,可以查询该目录下哪些大文件,然后依次rm删除无用的占用内存的文件.
参考:https://blog.csdn.net/qq_34246965/article/details/110038468

我也有遇见过此类问题，一般都是重启完事，因为磁盘坏道损坏有可能导致此问题。或 DF -i 查看inode使用率，inode不够用也会导致此问题。可看了inode也够用

[root@ackh-office-srv docker]# df -i
文件系统                Inode 已用(I)   可用(I) 已用(I)% 挂载点
/dev/mapper/cl-root   2826616 1329815   1496801      48% /
devtmpfs             12347387     515  12346872       1% /dev
tmpfs                12351426       6  12351420       1% /dev/shm
tmpfs                12351426     853  12350573       1% /run
tmpfs                12351426      16  12351410       1% /sys/fs/cgroup
/dev/md126p2           524032     374    523658       1% /boot
/dev/mapper/cl-home 550984064  964487 550019577       1% /home
tmpfs                12351426       4  12351422       1% /run/user/0
tmpfs                12351426      17  12351409       1% /run/user/42
overlay               2826616 1329815   1496801      48% /var/lib/docker/overlay2/7388d1c81c4cd4a42b629d9a1f156c022474444436c4683396d8b2d6ed0436c2/merged
shm                  12351426       1  12351425       1% /var/lib/docker/containers/1cd6335f1b67041fcd4a43617288cfd9fd0c534b0066de2156eadda00d433bb5/shm
overlay               2826616 1329815   1496801      48% /var/lib/docker/overlay2/883ab66c0922719519e6a17e409428e703b009cd4e2f6566ac1a9fb480eed671/merged
shm                  12351426       1  12351425       1% /var/lib/docker/containers/00da0f419c08f9163ead3ad8b29f964a9679996dc3d9453a41679c05eb8b9840/shm
overlay               2826616 1329815   1496801      48% /var/lib/docker/overlay2/b51eb5f1f20b4636693e590af65c9187a55ad6ea5485bfc88b49af1f2e9e8577/merged
shm                  12351426       2  12351424       1% /var/lib/docker/containers/9306555ac084a7fa5529c2216d906543db215d910ca74715b8ebb61c7d19bac1/shm
overlay               2826616 1329815   1496801      48% /var/lib/docker/overlay2/8cf90078979cbf73dc6d21f47a57af9dc80e4ce4461898ad2d70870667d58615/merged
shm                  12351426       1  12351425       1% /var/lib/docker/containers/10d1a1ea1506619a1b27305e5c6a709f389a8a5cf3dac69d7288472a2bec7e07/shm

在这期间,我还把/var下的docker的json日志和/opt下的java nohup.out文件删除. `rm -rf XXXX.json.log以及rm -rf nohuo.out`,发现磁盘空间没有减少,也就是没有变化.后来我找了资料,这叫僵尸文件,大意说文件虽然删除,但是进程还在,占的磁盘是不会释放的.且干掉该`(deleted)`进程有可能造成程序崩溃,停止运行,因为产生僵尸文件的进程是webapp应用，不能被kill，kill后，将会影响生产环境业务，但是磁盘也已经满了

解决问题:

得知删除文件还存在僵尸文件这种诡异的事后，看是否有状态为delete的文件

`lsof |grep delete`

COMMAND：进程的名称
PID：进程标识符
PPID：父进程标识符（需要指定-R参数）
USER：进程所有者
PGID：进程所属组
FD：文件描述符，应用程序通过文件描述符识别该文件。

[root@ackh-office-srv docker]# lsof |grep delete
command     PID PPID               USER   FD      type             DEVICE       SIZE         NODE            NAME
dockerd    1786 30961              root   38w      REG              253,0    4803128280    78891062 /var/lib/docker/containers/00da0f419c08f9163ead3ad8b29f964a9679996dc3d9453a41679c05eb8b9840/00da0f419c08f9163ead3ad8b29f964a9679996dc3d9453a41679c05eb8b9840-json.log (deleted)
java       3754                 jenkins   19r      REG              253,0       1484022   117579852 /tmp/jna4559948622136446323jar (deleted)
java       3754                 jenkins   22r      REG              253,0       2283188   117579857 /tmp/winstone4139804245682449191.jar (deleted)
qtp739498  3754  1610           jenkins   19r      REG              253,0       1484022   117579852 /tmp/jna4559948622136446323jar (deleted)
docker-co  4828                    root   21u     FIFO               0,19           0t0   101036059 /run/docker/containerd/1cd6335f1b67041fcd4a43617288cfd9fd0c534b0066de2156eadda00d433bb5/ff2708634883552f82185c36787788edf39efd14478bcac94da3d284fd90ca08-stdin (deleted)
PM2        6434                    root  cwd       DIR              253,0             6    20573326 /root/workspace/ackh_dcc/nuxt_dcc (deleted)
node       6434  6435              root  cwd       DIR              253,0             6    20573326 /root/workspace/ackh_dcc/nuxt_dcc (deleted)
tail       7559                    root    3r      REG              253,0        480157   111922606 /var/log/elasticsearch/mm-cluster-2020-09-06-1.log (deleted)
java      11332                    root  cwd       DIR              253,0             6      714168 /opt/online-read (deleted)
java      11332                    root    1w      REG              253,0       4296573      714170 /opt/online-read/nohup.out (deleted)
java      11332                    root    7r      REG              253,0     108837596     1371544 /opt/online-read/kkFileView-2.2.1-SNAPSHOT.jar (deleted)
java      11332 11333              root    7r      REG              253,0     108837596     1371544 /opt/online-read/kkFileView-2.2.1-SNAPSHOT.jar (deleted)
Service   11332 11368              root    1w      REG              253,0       4296573      714170 /opt/online-read/nohup.out (deleted)
)
PM2       16490                    root  cwd       DIR              253,0             6    20573326 /root/workspace/ackh_dcc/nuxt_dcc (deleted)
node      16490 16491              root  cwd       DIR              253,0             6    20573326 /root/workspace/ackh_dcc/nuxt_dcc (deleted)
java      18590                    root    1w      REG              253,0    5013822064    36434113 /opt/dcc_back/nohup.out (deleted)
java      18590                    root   57r      REG              253,0       1058776    33851535 /tmp/tomcat.4477088410858248213.8090/work/Tomcat/localhost/ROOT/upload_ece08897_119e_4133_9eb9_81dad51ec380_00000016.tmp (deleted)
http-nio- 18590  2570              root    2w      REG              253,0    5013822064    36434113 /opt/dcc_back/nohup.out (deleted)
http-nio- 18590  2570              root   57r      REG              253,0       1058776    33851535 /tmp/tomcat.4477088410858248213.8090/work/Tomcat/localhost/ROOT/upload_ece08897_119e_4133_9eb9_81dad51ec380_00000016.tmp (deleted)
java      19617                    root  cwd       DIR              253,0             6    20573326 /root/workspace
C1        19617 19652              root    7r      REG              253,0     108837686      714112 /opt/online-read/kkFileView-2.2.1-SNAPSHOT.jar (deleted)
VM        19617 19654              root    1w      REG              253,0         23307    21372120 /root/workspace/ackh_dcc/nuxt_dcc/nohup.out (deleted)
PM2       16490 16498              root  cwd       DIR              253,0             6    20573326 /root/workspace/ackh_dcc/nohup.out (deleted)

得到僵尸文件名称：

/opt/dcc_back/nohup.out以及/var/lib/docker/containers/00da0f419c08f9163ead3ad8b29f964a9679996dc3d9453a41679c05eb8b9840-json.log (deleted)

json.log进程号为1786

可以粗暴使用kill -9 pid

`kill -9 1786`

可以粗暴使用kill -9 1786,但注意可能会影响进程的运行这个内容中只有日志，不会被它处调用，所以直接删除进程是可行的。(产生nohup.out以及一些读写报告的僵尸文件的进程是webapp应用，kill后，再次启动就好,这将会影响暂时生产环境业务)

也可以这样说delete状态的文件指向很多不同端口监听，并且有几十个已建立的连接,要是kill掉,父进程可能运行异常

占用数据盘资源的是一个运行中的jar包，这个jar包以nohup形式运行，之前运维没有关闭nohup.out的输出导致出现了这么大的僵死文件。
我的做法是将其kill后再次启动，将结果送到回收站，以后可以避免出现这些问题。

再次启动时候可以用
nohup java -jar XXXX.jar >/dev/null 2>&1 &

/dev/null 表示将标准输出信息重定向到"黑洞"

2>&1 表示将标准错误重定向到标准输出(由于标准输出已经定向到“黑洞”了，即：标准输出此时也是"黑洞"，再将标准错误输出定向到标准输出，相当于错误输出也被定向至“黑洞”)

完后问题解决完毕，磁盘占用恢复正常。

不影响业务运行解决磁盘空间方法如下

`例如 /root/workspace/ackh_dcc/nohup.out (deleted)的进程号为16490`

进入虚拟文件系统对应进程目录(cd /proc/16490/fd),将僵尸文件清空

`cd /proc/16490/fd`

注意，不用直接删除进程产生的僵尸文件，可能会影响进程的运行，这里我们不删除，只是清理文件中产生的内容(使用echo命令)，这个内容中只有日志，不会被它处调用，所以直接删除是可行的。

`ll |grep nohup.out` //查看该进程虚拟文件路径下是否含有该文件

`echo '' > 1` 　　　　　　//写一个空的1文件进去,重置空间

`df -h` 　　　　//查看磁盘空间