我發現磁盤空間不足後，剛開始的思路是到/下通過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 表示将标準錯誤重定向到标準輸出(由于标準輸出已經定向到“黑洞”了，即：标準輸出此時也是"黑洞"，再将标準錯誤輸出定向到标準輸出，相當于錯誤輸出也被定向至“黑洞”)
完後問題解決完畢，磁盤占用恢複正常。