我发现磁盘空间不足后，刚开始的思路是到/下通过du -sh 来查找大文件，删了几个备份文件和一些没用的日志记录之后，虽然可以将占用降到80%左右，但是还是挺高的（红框是nfs挂载）
除去nfs挂载的文件，其余文件怎么可能将20G占用的所剩无几呢
得知这个方案不可行后，考虑了其他查询方案，看是否有状态为delete的文件
(僵死文件。这些文件实际上已经被删除，但是有服务程序在使用这些文件，导致这些文件一直被占用，无法释放磁盘空间，使用如下命令可以查看死文件占用情况）
lsof |grep deleted //在opt目录下执行lsof |grep deleted 如附件，表红区域为这个僵死文件的大小（单位为字节Bytes）。
当时在这里我可以看到几个很大的文件是delete状态，一下就点通了我。
就在准备kill掉他的时候，又出现一个问题，delete状态的文件最终指向一个端口监听，并且有几十个已建立的连接，我不知道这个端口的作用，通过ps命令看到这个端口的进程id，跟一个项目是有关联的，但是这个项目已经停止使用了，且早就被我shutdown了。
这个端口监听我死活找不到是哪个项目监听的这个端口，由于是项目不是完全熟悉了，不知道这是什么个情况，起初还以为有其他的项目使用着这个项目的配置文件啥的，但是想了想有不太可能，跟之前运维确定了没有过这个端口的使用后，就将其kill了，kill后，系统盘占用立马恢复正常，恢复到了开头的那个状态，这个情况可能是tomcat的某些bug导致，虽然项目停止，但是连接还是建立着，这个项目停止了有几天了，这些已建立的连接还是已建立（难道client端不发送连接断开请求，不关机吗）。。
由于tomcat内部机制并不了解，这个话题就到此结束。
这样起来处理数据盘资源占用就轻松多了
占用数据盘资源的是一个运行中的jar包，这个jar包以nohup形式运行，之前运维没有关闭nohup.out的输出导致出现了这么大的僵死文件。
我的做法是将其kill后再次启动，将结果送到回收站，以后可以避免出现这些问题。
| 1 | |
>/dev/null 表示将标准输出信息重定向到"黑洞"
2>&1 表示将标准错误重定向到标准输出(由于标准输出已经定向到“黑洞”了，即：标准输出此时也是"黑洞"，再将标准错误输出定向到标准输出，相当于错误输出也被定向至“黑洞”)
完后问题解决完毕，磁盘占用恢复正常。