磁盘和 inode 属于那種平时没人看、出了事才發現要命的指标。站点运营里大家习惯盯排名、盯抓取、盯内容更新，但服務器寫不進東西的时候，前面這些動作都會失效。
一、磁盘寫满，前台頁面可能還開着
磁盘快满的时候，最先报警的往往不是静態頁面。已经生成的 HTML 和图片還在硬盘上，訪客点開還是能看。真正先撑不住的是需要寫入的部分：資料库寫不進去、會话存不下来、頁面缓存生成失敗、图片上传中断、訪問日誌停止记錄。表現出来就是後台报错、發布文章失敗、评论提交無响應，或者部分頁面直接返回 500。
對蜘蛛来说，连續遇到 500 或超时，抓取频率通常會往下調，恢复起来也不快。
二、容量和 inode 是两回事
用 df -h 看的是空間，用 df -i 看的是 inode，也就是文件數量上限。這两個指标要一起看。
很多站点空間還空着一半，却已经無法建立新文件，原因就是小文件太多：缩略图、缓存分片、會话文件、日誌碎片、上传的临时文件。一個几 KB 的文件同样占用一個 inode，數量堆上去，先耗尽的是 inode 而不是容量。
- df -h 有空間、df -i 接近 100%：典型的 inode 耗尽。
- 两個都很高：容量和文件數量同时吃紧，清理时要更谨慎。
三、日常自查可以按這几步走
- 先看两個數字：df -h 和 df -i，把根分区、資料分区、日誌分区分開看，別只盯着一個 /。
- 找增長最快的目錄：用 du -sh 逐层往下看，配合按修改時間排序，重点關注缓存、日誌、上传、备份四類目錄。
- 日誌做轮轉：Web 訪問日誌、错誤日誌、應用日誌、定时任務日誌都配置 logrotate，按天或按大小切割並压缩，設定保留份數。
- 备份不要和資料放同一個分区。本地留一份最近的就够，歷史备份轉存到別的机器或對象存储。
- 資料库方面看 binlog、慢查询日誌和临时文件，定期清理過期 binlog，表碎片嚴重时安排维護窗口整理。
- 加监控和告警，容量與 inode 都设阈值，到 80% 就提醒，別等到 100%。
四、清理时容易踩的坑
- 正在被進程寫入的日誌文件，直接 rm 不一定释放空間，更稳的做法是先做轮轉，再刪除或压缩舊文件。
- 缓存目錄可以清，但別把目錄结构一起删掉，有些程序不一定能自動重建，權限也容易出問题。
- 上传目錄里的文件可能還被正文引用，清理前先確認引用關系，尤其是几年前的图片和附件。
- 資料库文件、系統临时目錄別手删，交给對應工具處理。
五、和抓取、收錄的關系
服務器磁盘出問题，會從几個方向影响蜘蛛：頁面返回 500 或超时，抓取频率下降；内容發布中断，新 URL 長時間没有實质内容；日誌寫不進去，你就失去了判断蜘蛛来訪的记錄。等服務器恢复後，抓取节奏通常需要一段時間才回到原来的水平。
所以排查流量波動时，先確認服務器狀態，再去看内容、内鏈、站点地图這些层面。
磁盘和 inode 是站点运营的地基，它不出問题的时候没人注意，一出問题，前面所有優化都要先停下。
把容量和 inode 纳入日常巡检，設定阈值提醒，定期清理日誌與备份，比事後救火省力得多。