已經很久沒有關注自己的博客了，待回來細看時，是不是發現文章下面自己寫的評論服務已經掛了。后來才知道原來是磁盤都滿了，那么如何來解決這個問題呢，接下來就大致簡單復現一下發現和解決問題的過程。

　　定位問題

第一步，還是到VPS搭建環境對應的管理面板下查看一下機器的狀態，貌似一切正常，除了這一抹紅色：

　　對，10G磁盤都滿了！這很有可能是導致評論服務掛掉的原因。所以，還是ssh登陸到服務器上去，看看到底是什么導致這10G內存（上次關注它的時候連10%都沒用到）都用完了。接下來，就需要在命令行里查詢具體是哪個目錄占了很多資源了。通過下面的這樣的指令，就可以發現是哪一塊在我沒關注的這一階段默默膨脹了。

　　df -h du -hs /* du -hs /root/* du -hs /var/log/*

　　果然，原來都是nginx的log搗的鬼（居然膨脹到了將近9G，那還得了）！

　　再cd到對應的目錄查看具體是哪個文件：

　　cd /var/log/nginx du -hs *

　　罪魁禍首應該就是這Ngnix的access.log

　　解決

　　問題的原因找到了，解決起來就簡單了。access.log記錄了所有的nginx處理的請求記錄，這肯定是隨著時間的積累，信息量已經越來越大，以至于到了這個地步。不過這個log現在對于我而言沒有太過價值，所以直接干脆 rm -rf 。/access.log 刪掉該文件。不過，當我開心地再次檢查內存狀況（df -h ）時，發現內存占用和之前一樣，依然有10G。這不科學？確實不科學，這個時候按經驗來說，很多人可能會選擇重啟服務器（但我還是不希望為了這個重啟云上的服務器）。網上大概了解下原因：可能存在一些運行進程在使用未鏈接（實際已經刪除了）的文件。所以，檢查一下是否這樣的進程在運行（其實，這時候基本上知道是nginx了）：

　　ls -ld /proc/*/fd/* 2》&1 | fgrep ‘（deleted）’

　　果然，就是nginx。只要重啟nginx服務就能夠讓 df 命令報出正式的內存狀況。

　　service nginx restart