在日常維護 Linux 服務器時，我們經(jīng)常會遇到這樣的場景：系統(tǒng)報錯提示“磁盤空間不足”，執(zhí)行 ls -l 看到一長串數(shù)字，或者 df -mh 發(fā)現(xiàn)根目錄掛載點進度條已經(jīng)變紅（98% 以上）。

今天就以一次真實的排查過程為例，分享如何科學地處理大文件與日志。

一、 識破數(shù)字：ls -l 里的 30482163185 到底有多大？

當你執(zhí)行 ls -l 時，文件大小默認是以 Byte（字節(jié)） 為單位顯示的。對于上百億的數(shù)字，肉眼很難直觀判斷。

1. 快速換算公式

計算機系統(tǒng)中，單位換算通常遵循 $1024$ 進制：

$$30482163185 \text{ B} \div 1024 \div 1024 \div 1024 \approx 28.39 \text{ GiB}$$

也就是說，這個文件占用了約 28.4 GB 的空間。

2. 懶人必備命令

與其手動計算，不如在執(zhí)行命令時加個 -h 參數(shù)（human-readable）：

• ls -lh：直接顯示為 29G。
• du -sh *：查看當前目錄下各個文件/文件夾的總大小。

二、 深度排查：為什么我的根目錄（/）滿了？

很多時候，我們發(fā)現(xiàn) /opt 或 /var 下有大文件，但并沒有意識到它們屬于哪個分區(qū)。

1. 尋找掛載點邏輯

通過 df -mh 命令可以觀察磁盤分布。如果你的輸出顯示 / 分區(qū)大小為 50G，而 /home 分區(qū)有 4.5T，那么：

• 如果 /opt 沒有獨立出現(xiàn)在“掛載點”一列，它就物理屬于根目錄（/）分區(qū)。
• 當 /opt 下產(chǎn)生一個 28G 的日志時，僅有 50G 的根目錄就會迅速告急（使用率直沖 98%）。

2. 空間不平衡的痛

這種“貧富差距”巨大的分區(qū)架構(gòu)（根目錄小、Home 目錄大）在 CentOS 等系統(tǒng)中很常見。最佳實踐是：將數(shù)據(jù)、日志、大型應用安裝在 /home 下，或者在 /home 創(chuàng)建目錄并軟鏈接到根目錄。

三、 治理長大的 nohup 日志：四種方案

程序運行產(chǎn)生的 1.log 越來越大，直接刪掉文件往往無法釋放磁盤（因為進程仍持有文件句柄）。我們需要更優(yōu)雅的處理方式：

方案 A：在線清理（急救）

不需要停止程序，直接清空內(nèi)容：

# 推薦方式，將文件置為 0 字節(jié)
true > 1.log
# 或者
cat /dev/null > 1.log

方案 B：重定向至“富裕”分區(qū)（治本）

既然 /home 有 4.4T 空間，為何不把日志放過去？

# 啟動時指定路徑
nohup ./start.sh > /home/logs/1.log 2>&1 &

方案 C：使用 logrotate（自動化）

利用 Linux 自帶的 logrotate 工具進行日志滾動。創(chuàng)建配置文件 /etc/logrotate.d/myapp：

/opt/app/1.log {
    daily
    rotate 5
    copytruncate    # 關鍵：先復制再清空，適合 nohup 進程
    compress
    missingok
}

方案 D：實時切分（進階）

利用 rotatelogs 等工具，在產(chǎn)生日志時就按大小或時間切分，避免單個大文件的出現(xiàn)。

四、 總結(jié)

1. 多用 -h 參數(shù)：無論是 ls -lh 還是 df -h，直觀的數(shù)據(jù)能幫你更快決策。
2. 警惕根目錄空間：核心系統(tǒng)分區(qū)一旦爆滿，可能導致 SSH 無法登錄、數(shù)據(jù)庫損壞等嚴重后果。
3. 日志必須治理：任何通過 nohup 啟動的服務，都必須考慮日志清理或切分策略。

到此這篇關于Linux服務器磁盤空間不足的排查與處理方法的文章就介紹到這了,更多相關Linux磁盤空間不足內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論