運維的監控系統發來通知,報告一臺服務器空間滿了,登錄服務器查看,根分區確實沒有空間了,以下圖所示:java
這裏首先說明一下服務器的一些刪除策略,因爲Linux沒有回收站功能,咱們的線上服務器全部要刪除的文件都會首先移動到系統/tmp目錄下,而後按期清除/tmp目錄下的數據。這個策略自己沒有問題,可是經過檢查發現這臺服務器的系統分區中並無單獨劃分/tmp分區,這樣/tmp下的數據實際上是佔用了根分區的空間。既然找到了問題,那麼刪除/tmp目錄下一些大數據便可,執行以下命令,檢查/tmp下最大的三個數據文件,以下圖所示:apache
[root@localhost~ ]# du -s /tmp/*|sort -nr|head -3 69206016 /tmp/access_log 36 /tmp/hsperfdata_root 36 /tmp/hsperfdata_mapred
經過命令輸出發如今/tmp目錄下有個66G大小的文件access_log,這個文件應該是apache產生的訪問日誌文件,從日誌大小來看,應該是好久沒有清理apache日誌文件了,基本斷定是這個文件致使的根空間爆滿,在確認此文件能夠刪除後,執行以下刪除操做:服務器
[root@localhost ~]# rm /tmp/access_log
接着查看系統根分區空間是否釋放,以下圖所示:運維
從輸出能夠看到,根分區空間仍然沒有釋放,這是怎麼回事?大數據
通常說來不會出現刪除文件後空間不釋放的狀況,可是也存在例外,好比文件被進程鎖定,或者有進程一直在向這個文件寫數據等等,要理解這個問題,就須要知道Linux下文件的存儲機制和存儲結構。spa
一個文件在文件系統中的存放分爲兩個部分:數據部分和指針部分,指針位於文件系統的meta-data中,數據被刪除後,這個指針就從meta-data中清除了,而數據部分存儲在磁盤中,數據對應的指針從meta-data中清除後,文件數據部分佔用的空間就能夠被覆蓋並寫入新的內容,之因此出現刪除access_log文件後,空間還沒釋放,就是由於httpd進程還在一直向這個文件寫入內容,致使雖然刪除了access_log文件,但文件對應的指針部分因爲進程鎖定,並未從meta-data中清除,而因爲指針並未被刪除,那麼系統內核就認爲文件並未被刪除,所以經過df命令查詢空間並未釋放也就不足爲奇了。操作系統
既然有了解決問題的思路,那麼接下來看看是否有進程一直在向acess.log文件中寫數據,這裏須要用到Linux下的lsof命令,經過這個命令能夠獲取一個已經被刪除但仍然被應用程序佔用的文件列表,命令執行以下圖所示:指針
從輸出結果能夠看到,/tmp/acess.log文件被進程httpd鎖定,而httpd進程還一直向這個文件寫入日誌數據,從第七列可知,這個日誌文件大小僅70G,而系統根分區總大小才100G,由此可知,這個文件就是致使系統根分區空間耗盡的罪魁禍首,在最後一列的「deleted」狀態,說明這個日誌文件已經被刪除,但因爲進程還在一直向此文件寫入數據,空間並未釋放。日誌
到這裏問題就基本排查清楚了,解決這一類問題的方法有不少種,最簡單的方法是關閉或者重啓httpd進程,固然也能夠重啓操做系統,不過這並非最好的方法,對待這種進程不停對文件寫日誌的操做,要釋放文件佔用的磁盤空間,最好的方法是在線清空這個文件,能夠經過以下命令完成:code
[root@localhost ~]# echo " " >/tmp/acess.log
經過這種方法,磁盤空間不但能夠立刻釋放,也可保障進程繼續向文件寫入日誌,這種方法常常用於在線清理Apache、Tomcat、Nginx等Web服務產生的日誌文件。