linux解決文件已刪除空間不釋放的問題

1、錯誤現象

運維的監控系統發來通知,報告一臺服務器空間滿了,登錄服務器查看,根分區確實沒有空間了:

<code>[root@localhost ~]# df -h/<code>

這裡首先說明一下服務器的一些刪除策略,由於Linux沒有回收站功能,所以線上服務器上所有要刪除的文件都會先移動到系統/tmp目錄下,然後定期清除/tmp目錄下的數據。這個策略本身沒有問題,但是通過檢查發現這臺服務器的系統分區中並沒有單獨劃分/tmp分區,這樣/tmp下的數據其實佔用了根分區的空間。既然找到了問題,那麼刪除/tmp目錄下一些佔空間較大的數據文件即可,檢查/tmp下最大的三個數據文件。

<code>[root@localhost ~]# du -sh /tmp/*|sort -nr|head -3/<code>

通過命令輸出發現在/tmp目錄下有個66GB大小的文件access_log,這個文件應該是Apache產生的訪問日誌文件,從日誌大小來看,應該是很久沒有清理Apache日誌文件了,基本判定是這個文件導致的根空間爆滿,在確認此文件可以刪除後,執行如下刪除操作:

<code>[root@localhost~]#rm/tmp/access_log/<code>

接著查看系統根分區空間是否釋放:

<code>[root@localhost ~]# df -h/<code>

從輸出可以看到,根分區空間仍然沒有釋放,這是怎麼回事?

2、解決思路

一般來說不會出現刪除文件後空間不釋放的情況,但是也存在例外,比如文件被進程鎖定,或者有進程一直在向這個文件寫數據等,要理解這個問題,就需要知道Linux下文件的存儲機制和存儲結構。

一個文件在文件系統中的存放分為兩個部分:數據部分和指針部分,指針位於文件系統的meta-data中,在將數據刪除後,這個指針就從meta-data中清除了,而數據部分存儲在磁盤中。在將數據對應的指針從meta-data中清除後,文件數據部分佔用的空間就可以被覆蓋並寫入新的內容,之所以在出現刪除access_log文件後,空間還沒釋放,就是因為httpd進程還在一直向這個文件寫入內容,導致雖然刪除了access_log文件,但是由於進程鎖定,文件對應的指針部分並未從meta-data中清除,而由於指針並未刪除,系統內核就認為文件並未刪除,因此通過df命令查詢空間並未釋放也就不足為奇了。

3、問題排查

既然有了解決問題的思路,那麼接下來看看是否有進程一直在向access_log文件中寫數據,這裡需要用到Linux下的lsof命令,通過這個命令可以獲取一個仍然被應用程序佔用的已刪除文件列表,命令執行如下:

<code>[root@localhost ~]# lsof | grep delete/<code>

從輸出結果可以看到,/tmp/access_log文件被進程httpd鎖定,而httpd進程還一直向這個文件寫入日誌數據。從第7列可知,這個日誌文件大小約70GB,而系統根分區總大小才100GB,由此可知,這個文件就是導致系統根分區空間耗盡的罪魁禍首。最後一列的“deleted”狀態說明這個日誌文件已經被刪除,但由於進程還在一直向此文件寫入數據,因此空間並未釋放。

4、解決問題

到這裡問題就基本排查清楚了,解決這一類問題的方法有很多種,最簡單的方法是關閉或重啟httpd進程,當然也可以重啟操作系統,不過這些並不是最好的方法。對待這種進程不停對文件寫日誌的操作,要釋放文件佔用的磁盤空間,最好的方法是在線清空這個文件,具體可以通過如下命令完成:

<code>[root@localhost~]#echo"">/tmp/acess.log/<code>

通過這種方法,磁盤空間不但可以馬上釋放,也可保障進程繼續向文件寫入日誌,這種方法經常用於在線清理Apache、Tomcat、Nginx等Web服務產生的日誌文件。


分享到:


相關文章: