今天通過監控，監控到某臺服務器上的/home目錄滿了；通過df? -Th ,如下圖顯示：
上圖中顯示：/home，Used%率達到100%；
隨后用du? -sh ,發現/home總共才73G；
而且在/home目錄下并沒有找到大文件；看起來好詭異。
“df”命令報告使用了多少個磁盤塊，同時“du”遍歷文件系統，并報告所使用的區塊的實際數量（按目錄下的目錄），包括與進程使用的文件相關的任何內容。
在大多數情況下，從“df”和“du”返回的空間利用率將是一致的。但是，對于一個正在運行的進程來說，刪除一個大文件的潛力是存在的。在這個例子中，根據“du”，大文件不再存在，因此與刪除文件相關聯的區塊不會被報告。隨著進程仍在運行，并且仍然保留著對已刪除文件的開放文件描述符，“df”繼續跟蹤和報告所使用的所有磁盤塊，包括與已刪除（幻影）文件相關聯的磁盤塊。在這種情況下，與被刪除的文件相關聯的磁盤空間只會在進程完全釋放被刪除的文件描述符或進程終止時（被殺死）時被釋放回系統。
??? 解決方案
????????? 解決方案是識別并停止（或殺死）繼續為已刪除文件打開文件描述符的過程。要做到這一點，請運行lsof命令（/usr/sbin/lsof ）作為根來識別扣留過程，例如：
?????????????????? ?????????????????? #lsof?? /home/? 找出持有/home目錄下文件的進程
?????????????????? #lsof? | grep deleted?? 數量太多的話，直接過濾出來，kill掉
下圖中，發現都是faclcon-ag進程運行時，刪除的一些日志文件；文件被刪除了，但是進行還在運行著。殺掉這些進程，空間就可以得到釋放。
之所以df和du命令看到的空間使用會有差別，原因在于du不統計已經刪除的文件，df會統計已經刪除的文件，但該文件依然被進程持有，只有等進程釋放了該文件，df才不進行統計。通過lsof | grep deleted命令可以找出被刪除的文件依然被進程持有的情況。
?????????? 總結：對于此類問題，我們首先要明白為什么df和du在空間計算上有所差別，其次要熟悉lsof和fuser兩個命令，找出繼續持有文件的進程號，通過該進程號可以在/proc目錄下恢復文件，查看進程的環境信息，甚至殺掉進程來釋放空間。
本文來自投稿，不代表Linux運維部落立場，如若轉載，請注明出處：http://www.www58058.com/98763
