服務器磁盘空間和日誌增長，平时不太起眼，出問题时却往往不是小問题。磁盘一旦寫满，網站可能先從响應變慢開始，接着出現資料库寫入失敗、缓存無法落盘、日誌寫不進去，嚴重时直接返回 5xx 错誤。對搜尋蜘蛛来说，抓取到的就是超时、错誤頁或半截内容，URL 發現和後續抓取都會受影响。
磁盘寫满时，抓取會先感受到什么
磁盘空間不足對抓取的影响不是一步到位的，通常有几個阶段：
- 响應時間上升：資料库查询、文件讀寫變慢，頁面生成時間拉長。
- 寫入失敗：日誌、缓存、會话文件寫不進去，程序開始报错。
- 部分功能不可用：上传、评论、搜尋索引更新等依赖寫入的模块先出問题。
- 直接返回错誤頁：Web 服務或應用返回 500、502、503，蜘蛛收到错誤狀態碼。
如果站点同时開了爬虫日誌，磁盘寫满後日誌也會中断，排查时反而缺少记錄。所以磁盘和日誌增長要放在日常运维里看，而不是等报警了再處理。
先看哪些目錄最容易膨胀
不同站点结构不一样，但下面几類文件通常是磁盘增長的主要来源：
- 訪問日誌和错誤日誌：Web 服務器、應用、資料库各自有日誌，長期不切割會一直追加。
- 應用日誌：調试日誌、任務日誌、第三方接口日誌，容易因為一次異常大量刷寫。
- 缓存文件：頁面缓存、對象缓存、模板编译缓存，數量多时占用不小。
- 临时文件：系統 /tmp、上传临时目錄、導出文件、压缩包。
- 备份文件：本地备份如果長期不清理，往往比站点本身還大。
- 上传目錄：图片、视频、附件随着内容更新持續增加。
- 資料库文件：資料文件、binlog、慢查询日誌、临时表。
還有一個容易被忽略的指标是 inode。即使剩余空間看起来不少，小文件過多也可能把 inode 用完，導致無法建立新文件。
一次可执行的磁盘自查顺序
- 先看整体使用率：確認是哪個分区接近寫满，不要只看根分区。
- 按目錄排序：從站点根目錄、日誌目錄、缓存目錄、备份目錄逐层看占用。
- 找出大文件：關注單個特別大的日誌、备份包、導出文件。
- 检查 inode 使用率：如果空間够但 inode 高，重点找小文件堆积的目錄。
- 检查日誌轮轉：確認 logrotate 或應用自带的轮轉是否生效，保留天數是否合理。
- 检查备份策略：本地备份保留几份、是否压缩、是否同步到异地。
- 检查临时目錄：上传临时文件、會话文件、導出文件是否定期清理。
- 检查資料库：binlog 是否按策略清理，慢查询日誌是否一直開着且未切割。
這個顺序的好處是先定位再動手，避免一上来就批量刪除，把有用的文件也清掉。
清理时容易踩的坑
- 直接刪除正在寫入的日誌文件：文件句柄没释放，空間不會立刻回收，需要让進程重新打開日誌或先清空再轮轉。
- 把备份当垃圾清掉：清理前確認备份可用，至少保留一份近期可恢复的副本。
- 誤删上传文件：上传目錄里可能混着临时文件和正式附件，按扩展名和修改時間篩選更稳妥。
- 一次清空全部缓存：缓存清空後請求會集中回源，短時間压力上升，可能让抓取也變慢。
- 忽略 inode：只看容量不看 inode，問题會反复出現。
把日誌轮轉和监控固定下来
磁盘問题很难靠临时清理解决，更稳的做法是把它變成固定動作：
- 為 Web、應用、資料库日誌設定轮轉，按天或按大小切割，保留 7 到 30 天，歷史日誌压缩归档。
- 為磁盘使用率、inode 使用率設定监控阈值，比如 80% 提醒、90% 告警。
- 把本地备份保留策略寫清楚，定期检查恢复流程，而不是只看备份文件在不在。
- 對临时目錄和上传目錄設定清理任務，避免只增不减。
這些動作不需要很复杂，但要坚持。對站点运营来说，磁盘稳定意味着頁面能正常生成、日誌能持續记錄、蜘蛛来訪时不會撞上错誤頁。
磁盘自查的目标不是把空間清到最大，而是让寫入、日誌和抓取记錄保持连續。留出余量，比事後救火更省事。