背景
最近一直收到產(chǎn)品環(huán)境其中一臺server的磁盤占用超過90%的警告旨涝，之前為了解決這個問題編寫了一個壓縮和刪除歷史log的腳本咧最，正常情況來說應該不會再報這個警告，因為腳本是每天都在跑，所以每天增長的log的大小應該不至于占用很多的磁盤空間馏谨，但是實際情況卻是每隔兩三天就會收到一次警告笆制，然后不得不手動的清理一些還沒有被腳本壓縮以及刪除的log，從而釋放一些空間，但是這不是長久之計买喧，所以就詳細的去查了這個問題瑟匆。
解決
再次受到這個警告之后黄娘，我通過SSH連到了這臺機器骨杂，然后通過df -h的命令查看了一下各個掛載磁盤的使用率如下圖：
從圖中可以看到可以看到 /dev/xvdb1這個磁盤被掛載在/alidata1/這個目錄下，并且已經(jīng)使用了34G(90%).
然后就要查看/alidata1下到底是哪個文件或者文件夾占用了這么多的磁盤空間莫瞬，我們通過du -h --max-depth=1來查看儡蔓，如下圖：
我們可以看到 /alidata1下的所有文件及文件夾占用的空間是22G，和我們通過df -h查看出來的磁盤占用34G相差12G疼邀，這是為什么喂江？這12G的空間到底是被誰占用了？
于是去網(wǎng)上查了一些資料旁振，原來是因為在Linux上刪除一個進程正在寫入的文件的時候获询，雖然已經(jīng)被我們刪除了，但是只要進程還在规求，那個文件就不會真正被刪除筐付，只是被臨時存放到系統(tǒng)的某個地方，有點類似于Windows的回收站阻肿。通過lsof可以查看沒有被真正刪除的文件瓦戚。如下圖
從圖中我們可以看出有四個占用空間比較大的沒有被真正刪除的文件，這四個文件分別是809和808的java進程console的輸出log丛塌。之前被手動刪除较解，但是由于沒有重啟進程導致文件一直還在，占用了大量空間赴邻。在通過重啟808和809的java進程之后印衔，磁盤的警告恢復了，通過df和du查看的結(jié)果如下：
df -h
du -sh /alidata1/
從新的結(jié)果中可以看到df查看的磁盤占用空間和du查看的文件中下文件的占用空間一致了姥敛。
總結(jié)
所以如果以后碰到一些不合理的一些磁盤占用情況奸焙，我們可以通過df和du來查看磁盤占用空間和實際的文件占用空間是否有差異，如果有差異通過lsof命令查看有哪些沒有被真正刪除的文件，確認是被哪個進程占用与帆，通過重啟進程的方式來釋放這些空間了赌。
