問題原因&通用解決步驟

頻繁收到es資料節點磁碟使用監控告警，到es上檢視，磁碟使用率40%，因此登入該告警伺服器，df -h 檢視，如圖

發下根目錄使用超過了80%，因此持續告警，按照以往辦法，直接du檢視根目錄哪個目錄佔用最大，清理即可

根目錄超過了80%告警，其中data是資料盤，掛載在另外的檔案系統上，不屬於根目錄所在檔案系統。那麼直接使用du命令 du -h --max-depth=1 檢視根目錄哪個目錄佔用磁碟空間最大就行了

發下除了/data目錄，其它目錄屬於根目錄，加起來不過7G，那麼其它磁碟被什麼佔用了呢？

對於遇到df 和du結果不一致的情況，基本斷定是檔案雖然刪除了，但是檔案控制代碼仍然被持有，因此磁碟空間未釋放，可以使用lsof命令( list open files)檢視
檢視根目錄開啟的檔案，搜尋刪除的檔案 lsof -n / |grep deleted (這裡/是根目錄)

懷疑是程序25550或25587持有刪除檔案的控制代碼，分別檢視程序是哪些應用

分別是es應用和es中介軟體程序，大概原因是es應用程序25550持有刪除檔案的控制代碼導致的，因此重啟此應用即可（kill也可以，但是可能會引起生產問題）。

原理解釋：

du命令會對待統計檔案逐個呼叫fstat這個系統呼叫，獲取檔案大小。它的資料是基於檔案獲取的，所以有很大的靈活性，不一定非要針對一個分割槽，可以跨越多個分割槽操作。如果針對的目錄中檔案很多，du速度就會很慢了。
df命令使用的事statfs這個系統呼叫，直接讀取分割槽的超級塊資訊獲取分割槽使用情況。它的資料是基於分割槽元資料的，所以只能針對整個分割槽。由於df直接讀取超級塊，所以執行速度不受檔案多少影響。
du和df不一致情況
常見的df和du不一致情況就是檔案刪除的問題。當一個檔案被刪除後，在檔案系統 目錄中已經不可見了，所以du就不會再統計它了。然而如果此時還有執行的程序持有這個已經被刪除了的檔案的控制代碼，那麼這個檔案就不會真正在磁碟中被刪除， 分割槽超級塊中的資訊也就不會更改。這樣df仍舊會統計這個被刪除了的檔案。
 

如何記憶這3個命令
du ->Disk Usage
df ->Disk Free
lsof ->list open files

翻車記錄

重啟es後，發下磁碟佔用還是存在，沒辦法，先重啟了虛擬機器，還是一樣，最後無奈只能先unmount資料盤/data試試

然後du -h --max-depth=1

原來根目錄/data有資料，然後掛載了資料盤後，把原/data的內容隱藏了。
解決辦法：先遷移/data/資料，然後清除/data資料，然後掛載磁碟到/data，最後啟動es