磁盘和 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 纳入日常巡检，设置阈值提醒，定期清理日志与备份，比事后救火省力得多。