如何解決磁盤(pán)滿載的問(wèn)題
已經(jīng)很久沒(méi)有關(guān)注自己的博客了，待回來(lái)細(xì)看時(shí)，發(fā)現(xiàn)文章下面自己寫(xiě)的評(píng)論服務(wù)已經(jīng)掛了。雖然之前的大部分功能并沒(méi)有完全完成，但作為一個(gè)有追求的developer，怎么能坐視不管呢。接下來(lái)就大致簡(jiǎn)單復(fù)現(xiàn)一下發(fā)現(xiàn)和解決問(wèn)題的過(guò)程。
定位問(wèn)題
首先，這個(gè)評(píng)論服務(wù)是部署在 搬瓦工 下的(咳咳，別問(wèn)我為什么，自己鬧著玩的東西，就用便宜的VPS搭建咯)。第一步，還是到搬瓦工對(duì)應(yīng)的管理面板下查看一下機(jī)器的狀態(tài)，貌似一切正常，除了這一抹紅色:
對(duì)，10G磁盤(pán)都滿了!這很有可能是導(dǎo)致評(píng)論服務(wù)掛掉的原因。所以，還是ssh登陸到服務(wù)器上去，看看到底是什么導(dǎo)致這10G內(nèi)存(上次關(guān)注它的時(shí)候連10%都沒(méi)用到)都用完了。接下來(lái)，就需要在命令行里查詢具體是哪個(gè)目錄占了很多資源了。通過(guò)下面的這樣的指令，就可以發(fā)現(xiàn)是哪一塊在我沒(méi)關(guān)注的這一階段默默膨脹了。
- df -h
- du -hs /*
- du -hs /root/*
- du -hs /var/log/*
果然，原來(lái)都是nginx的log搗的鬼(居然膨脹到了將近9G，那還得了)!
再cd到對(duì)應(yīng)的目錄查看具體是哪個(gè)文件：
- cd /var/log/nginx
- du -hs *
罪魁禍?zhǔn)讘?yīng)該就是這Ngnix的access.log
解決
問(wèn)題的原因找到了，解決起來(lái)就簡(jiǎn)單了。access.log記錄了所有的nginx處理的請(qǐng)求記錄，這肯定是隨著時(shí)間的積累，信息量已經(jīng)越來(lái)越大，以至于到了這個(gè)地步。不過(guò)這個(gè)log現(xiàn)在對(duì)于我而言沒(méi)有太過(guò)價(jià)值，所以直接干脆 rm -rf ./access.log 刪掉該文件。不過(guò)，當(dāng)我開(kāi)心地再次檢查內(nèi)存狀況(df -h )時(shí)，發(fā)現(xiàn)內(nèi)存占用和之前一樣，依然有10G。這不科學(xué)?確實(shí)不科學(xué)，這個(gè)時(shí)候按經(jīng)驗(yàn)來(lái)說(shuō)，很多人可能會(huì)選擇重啟服務(wù)器(但我還是不希望為了這個(gè)重啟云上的服務(wù)器)。網(wǎng)上大概了解下原因：可能存在一些運(yùn)行進(jìn)程在使用未鏈接(實(shí)際已經(jīng)刪除了)的文件。所以，檢查一下是否這樣的進(jìn)程在運(yùn)行(其實(shí)，這時(shí)候基本上知道是nginx了)：
- ls -ld /proc/*/fd/* 2>&1 | fgrep '(deleted)'
果然，就是nginx。只要重啟nginx服務(wù)就能夠讓 df 命令報(bào)出正式的內(nèi)存狀況。
- service nginx restart
畢，回到最初的問(wèn)題上(是評(píng)論系統(tǒng)掛了)，刷新一下博客頁(yè)面，發(fā)現(xiàn)評(píng)論回來(lái)了。
簡(jiǎn)要回顧原因
不難看出，評(píng)論系統(tǒng)掛了其實(shí)是因?yàn)槠渌诘姆?wù)器上nginx服務(wù)運(yùn)行不正常。nginx服務(wù)運(yùn)行不正常是因?yàn)樗涗浀膌og已經(jīng)撐滿了整個(gè)硬盤(pán)?？磥?lái)后期得給nginx加上log壓縮或者定期清理任務(wù)了。但是，還是等我先把這個(gè)評(píng)論系統(tǒng)的“評(píng)論”功能實(shí)現(xiàn)吧，啊哈哈哈[羞恥笑]。
Reference
