很多站点故障的起点並不是代碼寫错了，而是服務器上的磁盘被慢慢寫满。表現往往很零散：後台儲存文章失敗、图片上传报错、缓存文件生成不了、資料库寫入變慢，甚至整個站点開始間歇性 502。因為磁盘不是一下子满的，而是几天、几周累积出来的，所以很容易被当成“偶發問题”忽略過去。
為什么磁盘寫满會连累整站
磁盘空間和内存不一样，它满了不會有明顯提示音。常见的连鎖反應包括：
- 會话文件、临时文件寫不進去，用戶登入狀態随机丢失；
- 資料库無法寫入或無法生成临时表，查询變慢甚至报错；
- 日誌寫入失敗後，程序可能反复重试，進一步拖慢响應；
- 某些進程因為拿不到鎖或寫不了文件而卡死，占用连接數。
這些現象看起来互不相關，但排查到後面常常指向同一個原因：可用空間不足，或者 inode 用尽。後者尤其容易被忽略——容量顯示還有几十 GB，但小文件太多，inode 已经耗尽，同样寫不進任何新文件。
先看三個數字，再谈優化
遇到疑似磁盘問题，建议按固定顺序看三個指标，而不是直接動手删文件。
- 分区使用率：用 df -h 看各挂载点，重点看站点目錄、日誌目錄、資料库目錄所在分区。
- inode 使用率：用 df -i 看，如果 inode 接近 100%，說明小文件太多，刪除大文件没有用。
- 目錄占用排名：用 du 逐层往下看，先看 /var/log、站点上传目錄、缓存目錄、資料库資料目錄這几個常见位置。
只有先確認是“容量不足”還是“inode 不足”，後續處理方向才不會跑偏。
常见的占用大戶有哪些
日誌文件
訪問日誌、错誤日誌、爬虫日誌、應用調试日誌，是绝大多數服務器上增長最快的部分。尤其是開啟了详细調试級別、或者爬虫請求量較大的站点，日誌一天涨几個 GB 並不罕见。
缓存與临时文件
頁面缓存、缩略图缓存、模板编译文件、上传過程中的临时分片，如果清理策略缺失，會一直堆在磁盘上。這類文件的特点是單個不大，但數量极多，容易先把 inode 吃掉。
資料库與备份文件
資料库資料文件、二進制日誌、本地留存的备份压缩包，往往体积很大。本地备份如果長期保留多份，很容易在不知不觉中占掉大部分空間。
日誌轮轉该检查什么
日誌轮轉配置看起来简單，但出問题的情况不少，建议逐項確認：
- 轮轉周期是否合理，是否和站点實际日誌增長速度匹配；
- 保留份數是否明确，是否存在“保留 30 份但每份都很大”的情况；
- 压缩是否開啟，未压缩的舊日誌會持續占空間；
- 轮轉後寫入進程能否正确重新打開文件，避免出現“删了文件但空間没释放”的情况；
- 是否有權限問题導致轮轉任務静默失敗，日誌一直寫進同一個文件。
刪除一個仍被進程占用的日誌文件，磁盘空間不會立刻释放。遇到這種情况，需要让進程重新打開日誌文件，或者重啟對應服務，才能真正回收空間。
把检查動作固化下来
临时處理完一次，不等于問题解决。更稳妥的做法是把检查變成例行動作：
- 每天固定時間记錄一次各分区使用率和 inode 使用率，形成趋势資料；
- 設定阈值提醒，比如使用率超過 80% 或 inode 超過 85% 时發出通知；
- 每周確認一次日誌轮轉是否按预期执行，检查最近一份日誌的修改時間；
- 备份文件保留策略寫清楚，本地只留必要份數，其余轉移到其他存储；
- 每次上线新功能前，评估它會不會产生新的日誌或缓存目錄，並补齐清理策略。
這套動作本身不复杂，难点在于坚持。很多站点出問题，並不是不知道该看磁盘，而是没人定期看。
和站点运营的關系
從运营角度看，磁盘空間属于容易被归到“技術那邊的事”。但實际影响很直接：頁面打不開、訪客提交失敗、蜘蛛抓取拿到 5xx，损失的都是站点自己的流量和信任。把磁盘检查和内容更新、連結检查放在同一個例行程里，成本並不高，却能挡掉一類很典型的故障。
如果你現在還不确定服務器上哪块空間最紧張，不妨從 df -h 和 df -i 两條命令開始，先看清楚現状，再决定清理和轮轉策略。