Linux設備上沒有空間之覆盤

某天前端在調接口的時候，發現登陸頁面得驗證碼接口竟然沒有響應數據，顯示的是500響應碼。因而我一路排查，首先排查驗證碼接口所屬的微服務是否正常，經過lsof -i:服務端口進行排查，發現該微服務進程存在，同時我在服務註冊中心的服務管理列表也發現該服務正常註冊。結合以前遇到的問題，驗證碼接口報500，沒有及時響應數據，與Redis有關，驗證碼的數據會存放Redis，我再次排查Redis，發現Redis也正常，最後我看錯誤日誌。我排查該問題的步驟:

• 第一排查提供驗證碼的微服務是否正常；
• 第二排查服務註冊中心是否有該服務；
• 第三排查Redis是否正常運行；
• 最後查看日誌。
  最後我從錯誤日誌中看到了設備上沒有空間這樣的錯誤信息。當時我尚未意識到，多是Linux磁盤空間不足的緣由，下意識使用程序員的萬能絕招」重啓」，但」重啓」並無從根本上解決這個問題，這裏提到的」重啓」是指重啓Java應用而不是重啓Linux服務器。最後發現重啓也不能解決這個問題，因而我又下意識的以爲是內存的緣由，因而便直接關閉其它無需和前端對接口的微服務，忽然發現問題一下解決了。因而就沒有深究了。
  然後過了一個小時左右，前端又再次反饋其它接口有問題了，不能及時響應正確的數據，所有報500，這時我開始慌了，隱隱約約以爲問題並未從根本上解決，根本不是內存的緣由，這時我纔想起用free -m命令查看一下內存的使用，發現還有2個多G的內存，排除了內存不足的緣由，一般運行Java應用，內存不足會報以下異常:

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000794500000, 576716800, 0) failed; error='Cannot allocate memory' (errno=12)

這時我冷靜下來，看日誌信息，再次發現了這句話」設備上沒有空間」。因而經過關鍵字搜索，找到了問題所在，如圖所示:

 

 

結合Windows，形象地歸納，就是個人系統盤C盤滿了。

2、當時我很疑惑爲何/dev/mapper/centos-root一下就滿了呢？

我仔細想了下，發現我將不少軟件和服務以及日誌所有放在/usr下的某個目錄裏，因而我一路排查後，發現有這麼幾類文件佔用很大的空間:

• 日誌文件(Nacos日誌以及各項微服務日誌、MySQL日誌、系統日誌等足足10G以上，這時我終於明白了，爲何日誌要實時備份傳輸以及刪除了)；
• 遺留的軟件包和壓縮包(10G以上)；
• 靜態文件(離線地圖，足足佔了20G以上)和其它圖片文件；
• 項目源代碼以及打包成功後的jar(3個多G)；
• Maven倉庫(足足佔了5個多G)。

3、問題已經定位到了，那麼我是如何解決這個問題的？

問題的根源在於不合理的佔用系統盤空間，將這些不合理的從系統盤空間轉移出去便可，轉移到磁盤空間充足的，也就是/dev/mapper/centos-home下。

我作了這些事情:

• 備份日誌，下載到本地(目前備份服務器尚未申請下來，同時關於哪些須要保留的，須要內部協商探討)，原有的日誌進行刪除(這個工做能夠腳本化)；
• 遺留軟件包和壓縮包直接刪除；
• 靜態文件遷移至/home下的某個用戶目錄，經過配置進行映射(確保遷移後仍不影響正常的訪問)；
• 項目源代碼遷移到/home下的某個用戶目錄；
• 修改Maven配置文件，倉庫地址指向/home下的某個用戶目錄。

最終解決了這個問題，釋放了50%的空間，其中還有15%暫時不能動。
這樣一來，/dev/mapper/centos-root這個系統盤獲得了充分釋放，同時/dev/mapper/centos-home也獲得了充分利用(再也不資源閒置)。

4、問題列表和具體解決措施

1.如何經過Linux命令知道當前磁盤空間使用狀況?

命令格式以下:
du -sh 文件路徑

du -sh *

執行就能看到當前文件以及文件夾所佔用內存。佔用內存多的，可進一步查看究竟是什麼緣由佔用這麼多內存的。

下面就是我經過du -sh *命令查看內存佔用最多的文件或文件夾:

• Nacos;
• MySQL;
• Nginx;
• Project。

2.爲何Nacos會佔用這麼多內存呢？它僅僅是一個服務註冊中心並不對外提供服務。

經過du -sh 命令，我排查到原來是nacos下的bin目錄佔用內存最多，其它不多，因而我進一步查看，發現bin目錄下的log目錄佔用內存最多，由於該log目錄下主要是nacos的訪問日誌，最後我經過du -sh 命令查看，如圖所示:

 

 

由圖可知，平均一個日誌文件就是一百多M，足足佔了十幾個G也就不足爲奇了。

個人解決辦法很簡單，分爲兩個方面:
第一方面是定時刪除僅保留一個和備份遷移到/home下的某個目錄;
第二個方面經過修改nacos的配置解決，具體參考以下連接:
Nacos系列(4)-Nacos各類日誌太多問題的終極解決辦法

3.爲何MySQL會佔用這麼多磁盤空間？

經過命令排查(即du -sh *)，我發現是MySQL下的data目錄佔用磁盤空間最大，其中有一個足足佔了4個多G，針對這樣的問題，我將其直接由/usr/software目錄下遷移到/home下，這樣一來系統盤的空間再度獲得釋放，遷移後須要改mysql的配置文件(即my.cnf文件)。

4.Nginx爲什麼佔用這麼多磁盤空間？

之因此佔用這麼多，前面我提到過是由於離線地圖，離線地圖包括街道地圖和衛星地圖，兩個加在一塊兒足足二十多G，爲此我將其遷移到/home下的某個目錄，而後修改Nginx的核心配置nginx.conf文件進行映射，這樣一來系統盤的空間再次獲得釋放，同時用戶盤的空間獲得了充分利用。

5.關於Project

Project主要放源代碼和打包成功產生的jar，我仍是用老辦法將其遷移(遷移到/home下的某個目錄)。

5、問題的根本緣由是什麼？爲何我須要排查這麼長時間才定位到這個緣由呢？

問題的根本緣由在於不規範性。正常來講，不該該將用戶磁盤空間作的事情放在系統磁盤空間(與Windows同理)。從這一刻起，我也深深意識到規範性的重要，不規範性致使的bug何止千千萬萬，仔細想來個人開發經歷，形成bug的絕大多數緣由均是由於不規範，由於不規範，暴露出各類奇奇怪怪的bug。
另外從我排查問題來看也是頗有問題的，問題在於沒有用正確的態度對待日誌，其實一開始仔細排查日誌，定位到這個關鍵信息，而後將這樣的關鍵信息複製搜索引擎來尋找解決辦法，這樣一來就沒必要浪費了近一個多小時來搗鼓這樣的事情。

6、如何避免這樣的問題再現？以及經過這樣的問題總結出什麼樣的原則？

首先這樣的問題屬於運維範疇，而我做爲公司的兼職運維，面對這樣的問題，首先從規範入手，制定可行的規範，從根本上杜絕這樣的問題再現，對於這樣的問題，我總結的原則以下:

• (1)不一樣的用戶作不一樣的事情，保持Linux用戶的功能專注性(後面會提到一個重大bug,是由於違反這樣的原則致使的)；
• (2)遇到問題，分爲兩個方面來解決，見過和沒有見過，見過表示過去我遇到過這樣的問題，能夠借鑑以往經驗來快速解決這個問題；沒有見過的問題，嚴格遵照的流程:復現問題->仔細查看日誌->定位問題->解決問題->總結並存入知識庫(若有必要進行按期覆盤)。總而言之，最關鍵的在於定位問題(如何定位問題，可經過重複復現問題->仔細查看日誌這樣的步驟來定位；
• (3)針對常見運維需求，編寫腳本(如監控系統磁盤使用狀況以及用戶磁盤使用狀況，超出閾值，自動告警和人工干預)，推動腳本自動化；
• (4)制定適合當下狀況的運維規範(如安裝軟件安在哪一個目錄、大文件放在哪一個目錄、日誌存放多久並備份後自動清除、每一個用戶只作本身的事情等,根據實際狀況不斷增長和修訂，按期寫入文檔進行維護)。