资讯文章资讯 · NEWS

磁盘、inode 和日志膨胀：目录站被打满之后，搜索引擎看到的是一个 500 站

2026-10-23 约 1,880 字预计阅读 5 分钟 yiyunkj

服务器挂了会立刻被发现。磁盘满了不会——网站大部分页面还能打开，只有写入操作开始失败，报错零散，看起来像随机故障。

等它真的影响到搜索引擎的时候，通常已经满了好几天了。

磁盘 inode 与日志膨胀导致服务异常的排查顺序示意图

图片来源：网络，版权归原作者所有，侵权请联系删除

目录站上吃磁盘的四类东西

访问日志是第一名。一个日 IP 几千的目录站，开着完整访问日志，一天几百 MB 很正常。如果日志级别调成了 debug，或者某个中间件在疯狂刷错误日志，一天几 GB 也不奇怪。

访问日志之外还有：PHP/应用错误日志、数据库慢查询日志、cron 任务输出（没重定向的话全进了邮件或者某个文件）、以及容器环境的标准输出。

用户提交的 Logo、截图、附件。如果没有配额和清理机制，这里会一直长。更常见的是处理过程中产生的中间文件：缩略图生成到一半失败留下的碎片、图片处理的临时文件、导入失败的残留文件。

一个条目存五个尺寸的缩略图，一万个条目就是五万个文件。再加上这些文件通常都很小（几 KB），真正先打满的往往不是容量而是 inode 数量。

本地备份是最容易被忽略的一类。脚本每天跑一次全量备份存在本机，谁也没去看过，三个月后它就占了 60% 的磁盘。备份留在本机本身就是错误做法，但确实很常见。

这是个值得单独讲的坑。df -h 显示还有 40% 空间，但任何写入都报「No space left on device」。这时候看一下 df -i，inode 用完了。

inode 是文件系统的索引节点，每个文件占一个，跟文件大小无关。大量小文件是典型场景：缩略图碎片、session 文件、碎片化的缓存文件、未清理的临时文件。

症状很有辨识度：能读不能写，新建文件失败，但磁盘容量明明还有。第一次遇到的人通常会在那儿查半天权限。

磁盘满导致的故障模式通常是这样的：

到这一步，爬虫看到的就是一个持续返回错误的站点。谷歌在抓取相关文档里的建议是：5xx 期间应该返回 503 并带上 Retry-After，而且这种状态只适合维持数小时到一两天。长期 5xx 的结果不是「抓取延后」，而是页面被逐步移出索引。

这里有个反直觉的点值得记住：爬虫能容忍短暂的 503，容忍不了长期的 500。同样是「服务不可用」，带 Retry-After 的 503 是在沟通，500 是在失联。

还有一个连带影响：如果 robots.txt 也因为磁盘问题返回了 5xx，爬虫会认为整个站点暂时不可用，抓取全面暂停。恢复之后需要一段时间才能回到之前的抓取频率。

三档阈值，不要只设一档：

第三行比前两行重要。「还剩 30%」在静态看来很安全，但如果每天涨 5%，一周就出事。增长率能给你提前量。

另外要监控分区，不只是总量。日志单独挂一个分区是常见的做法，好处就是日志写满不会拖垮系统盘。

logrotate 是标配，几个要点：

最后那条兜底很重要。备份和日志都遵循同一个原则：清理机制本身不能依赖人记得去执行。

第 2 条很多人会忘。磁盘满的时候返回的通常是 500（写入异常导致的未捕获错误），而 503 + Retry-After 才是爬虫能理解的状态码。这两者对索引的影响差别不小。

一是给上传目录单独分区或者单独挂载，它写满了不影响系统运行。

二是备份脚本落地前先确认目标不在本机，且保留策略有上限。

三是把「磁盘和 inode 使用率」加进每周巡检报告。这个指标平时没人看，出事时已经是事故了，每周扫一眼就能提前一周发现。