解决进程文件句柄泄露导致磁盘空间无法释放问题

问题的产生

今天突然接到一台服务器磁盘空间使用率达到90%的报警，于是登陆机器查看磁盘使用情况，发现确实外挂到/data的一块磁盘使用率达到了90%：

[root@awsuw7-46 data]# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2      100G   17G   84G  17% /
devtmpfs         30G     0   30G   0% /dev
tmpfs            29G     0   29G   0% /dev/shm
tmpfs            29G  2.7G   27G  10% /run
tmpfs            29G     0   29G   0% /sys/fs/cgroup
/dev/xvdf       246G  209G   26G  90% /data
tmpfs           5.8G     0  5.8G   0% /run/user/1000
tmpfs           5.8G     0  5.8G   0% /run/user/1003

分析问题

对于这种情况我一般的处理方法是跳到对应的目录，查看哪个目录占用的空间比较大，然后进一步清理。由于这块磁盘是外挂到/data目录，因此查看下该目录下各个目录磁盘的占用情况：

[root@awsuw7-46 data]# du -h --max-depth=1
3.7G	./photo
16K	./lost+found
9.1G	./mls2
36K	./parser
79G	./web
15G	./mls
106G	.

可以发现一个奇怪的现象：该外挂目录总共才使用了106G，但是df -h显示的是该磁盘已经使用了209G，那么使用的另外那103G去哪儿了呢，况且这块磁盘也没有多个分区，就这一个分区且挂载到了/data下。这确实是个很奇怪的问题，于是网上搜索了下原因，原来是不正确的删除文件导致的：

在Linux操作系统中，当一个文件被删除后，在文件系统目录中已经不可见了，所以du就不会再统计它了。然而如果此时还有运行的进程持有这个已经被删除了的文件的句柄，那么这个文件就不会真正在磁盘中被删除，分区超级块中的信息也就不会更改，所以df命令查看的磁盘占用没有减少。我们知道在Linux中磁盘分区的超级块是非常重要的，在superblock中记录该分区上文件系统的整体信息，包括inode和block的总量，剩余量，使用量，以及文件系统的格式等信息。因此，superblock不更新，那么磁盘的使用量必然不会变化，操作系统对于文件的存盘都是需要事先读取superblock的信息，然后分配可用的inode和block。

解决问题

首先找出文件句柄泄露的进程，我的方法比较low，找出系统中启动时间比较久的java进程(因为这台机器主要是java服务)，然后用lsof看这个进程的文件句柄使用情况。之所以这么做主要是因为最近启动的进程发生句柄泄露的可能性很小，因为即使存在句柄泄露，重启后也会释放文件句柄的。可以看出2962这个进程最可能发生句柄泄露了。

[root@awsuw7-46 data]# ps -eo pid,lstart,comm | grep java
  746 Thu Jan 18 19:44:15 2018 java
 1117 Thu Feb  8 02:20:03 2018 java
 1160 Thu Feb  8 02:20:09 2018 java
 2962 Thu Nov 16 23:08:40 2017 java
 3610 Wed Feb  7 22:55:37 2018 java
 4579 Thu Feb  8 20:45:09 2018 java
 5155 Mon Dec 25 19:01:32 2017 java
 6481 Wed Jan 10 05:16:28 2018 java
 6519 Thu Jan 18 00:51:07 2018 java
 9756 Thu Feb  8 02:36:23 2018 java

使用lsof分析上面找到的进程文件句柄使用情况，可以看出该进程确实存在句柄泄露，而且非常严重，已经有2208个文件没有释放了：

[root@awsuw7-46 ~]# lsof -p 2962 | grep "delete" | wc -l
2208
[root@awsuw7-46 ~]# lsof -p 2962 | grep "delete" | head -n 20
java    2962  web   17r      REG              202,2     2098273   17844538 /tmp/winstone962950350375526798.jar (deleted)
java    2962  web  168w      REG             202,80           0    1969499 /data/web/mls/data/jobs/mls_91/builds/590/23.log (deleted)
java    2962  web  325w      REG             202,80           0    6455947 /data/web/mls/data/jobs/mls_39/builds/1080/10.log (deleted)
java    2962  web  341w      REG             202,80           0    1975873 /data/web/mls/data/jobs/mls_113/builds/1054/29.log (deleted)
java    2962  web  347w      REG             202,80           0    2506849 /data/web/mls/data/jobs/mls_59/builds/.1073/21.log (deleted)
java    2962  web  350w      REG             202,80        8192    1975877 /data/web/mls/data/jobs/mls_113/builds/1054/31.log (deleted)
java    2962  web  352w      REG             202,80           0    5387403 /data/web/mls/data/jobs/mls_80/builds/505/23.log (deleted)
java    2962  web  354w      REG             202,80           0    3422611 /data/web/mls/data/jobs/mls_29/builds/.385/23.log (deleted)

重启上面找到的发生内存泄露的进程，发起磁盘使用量回归正常状态：

[ec2-user@awsuw7-46 ~]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2      100G   17G   84G  17% /
devtmpfs         30G     0   30G   0% /dev
tmpfs            29G     0   29G   0% /dev/shm
tmpfs            29G  2.7G   27G  10% /run
tmpfs            29G     0   29G   0% /sys/fs/cgroup
/dev/xvdf       246G  128G  106G  55% /data
tmpfs           5.8G     0  5.8G   0% /run/user/1000
tmpfs           5.8G     0  5.8G   0% /run/user/1003
tmpfs           5.8G     0  5.8G   0% /run/user/1005
tmpfs           5.8G     0  5.8G   0% /run/user/1008
tmpfs           5.8G     0  5.8G   0% /run/user/1007
tmpfs           5.8G     0  5.8G   0% /run/user/1006

后来和工作同事确认了下，确实是他们写了个定时脚本清理这个进程产生的文件，而且是定期直接rm删掉，这必然会导致进程发生句柄泄露。

问题的产生

分析问题

解决问题

相关链接：