服务器磁盘空间和日志增长，平时不太起眼，出问题时却往往不是小问题。磁盘一旦写满，网站可能先从响应变慢开始，接着出现数据库写入失败、缓存无法落盘、日志写不进去，严重时直接返回 5xx 错误。对搜索蜘蛛来说，抓取到的就是超时、错误页或半截内容，URL 发现和后续抓取都会受影响。
磁盘写满时，抓取会先感受到什么
磁盘空间不足对抓取的影响不是一步到位的，通常有几个阶段：
- 响应时间上升：数据库查询、文件读写变慢，页面生成时间拉长。
- 写入失败：日志、缓存、会话文件写不进去，程序开始报错。
- 部分功能不可用：上传、评论、搜索索引更新等依赖写入的模块先出问题。
- 直接返回错误页：Web 服务或应用返回 500、502、503，蜘蛛收到错误状态码。
如果站点同时开了爬虫日志，磁盘写满后日志也会中断，排查时反而缺少记录。所以磁盘和日志增长要放在日常运维里看，而不是等报警了再处理。
先看哪些目录最容易膨胀
不同站点结构不一样，但下面几类文件通常是磁盘增长的主要来源：
- 访问日志和错误日志：Web 服务器、应用、数据库各自有日志，长期不切割会一直追加。
- 应用日志：调试日志、任务日志、第三方接口日志，容易因为一次异常大量刷写。
- 缓存文件：页面缓存、对象缓存、模板编译缓存，数量多时占用不小。
- 临时文件：系统 /tmp、上传临时目录、导出文件、压缩包。
- 备份文件：本地备份如果长期不清理，往往比站点本身还大。
- 上传目录：图片、视频、附件随着内容更新持续增加。
- 数据库文件：数据文件、binlog、慢查询日志、临时表。
还有一个容易被忽略的指标是 inode。即使剩余空间看起来不少，小文件过多也可能把 inode 用完，导致无法创建新文件。
一次可执行的磁盘自查顺序
- 先看整体使用率：确认是哪个分区接近写满，不要只看根分区。
- 按目录排序：从站点根目录、日志目录、缓存目录、备份目录逐层看占用。
- 找出大文件：关注单个特别大的日志、备份包、导出文件。
- 检查 inode 使用率：如果空间够但 inode 高，重点找小文件堆积的目录。
- 检查日志轮转：确认 logrotate 或应用自带的轮转是否生效，保留天数是否合理。
- 检查备份策略：本地备份保留几份、是否压缩、是否同步到异地。
- 检查临时目录：上传临时文件、会话文件、导出文件是否定期清理。
- 检查数据库：binlog 是否按策略清理，慢查询日志是否一直开着且未切割。
这个顺序的好处是先定位再动手，避免一上来就批量删除，把有用的文件也清掉。
清理时容易踩的坑
- 直接删除正在写入的日志文件：文件句柄没释放，空间不会立刻回收，需要让进程重新打开日志或先清空再轮转。
- 把备份当垃圾清掉：清理前确认备份可用，至少保留一份近期可恢复的副本。
- 误删上传文件：上传目录里可能混着临时文件和正式附件，按扩展名和修改时间筛选更稳妥。
- 一次清空全部缓存：缓存清空后请求会集中回源，短时间压力上升，可能让抓取也变慢。
- 忽略 inode：只看容量不看 inode，问题会反复出现。
把日志轮转和监控固定下来
磁盘问题很难靠临时清理解决，更稳的做法是把它变成固定动作：
- 为 Web、应用、数据库日志设置轮转，按天或按大小切割，保留 7 到 30 天，历史日志压缩归档。
- 为磁盘使用率、inode 使用率设置监控阈值，比如 80% 提醒、90% 告警。
- 把本地备份保留策略写清楚，定期检查恢复流程，而不是只看备份文件在不在。
- 对临时目录和上传目录设置清理任务，避免只增不减。
这些动作不需要很复杂，但要坚持。对站点运营来说，磁盘稳定意味着页面能正常生成、日志能持续记录、蜘蛛来访时不会撞上错误页。
磁盘自查的目标不是把空间清到最大，而是让写入、日志和抓取记录保持连续。留出余量，比事后救火更省事。