很多站点故障的起点并不是代码写错了，而是服务器上的磁盘被慢慢写满。表现往往很零散：后台保存文章失败、图片上传报错、缓存文件生成不了、数据库写入变慢，甚至整个站点开始间歇性 502。因为磁盘不是一下子满的，而是几天、几周累积出来的，所以很容易被当成“偶发问题”忽略过去。
为什么磁盘写满会连累整站
磁盘空间和内存不一样，它满了不会有明显提示音。常见的连锁反应包括：
- 会话文件、临时文件写不进去，用户登录状态随机丢失；
- 数据库无法写入或无法生成临时表，查询变慢甚至报错；
- 日志写入失败后，程序可能反复重试，进一步拖慢响应；
- 某些进程因为拿不到锁或写不了文件而卡死，占用连接数。
这些现象看起来互不相关，但排查到后面常常指向同一个原因：可用空间不足，或者 inode 用尽。后者尤其容易被忽略——容量显示还有几十 GB，但小文件太多，inode 已经耗尽，同样写不进任何新文件。
先看三个数字，再谈优化
遇到疑似磁盘问题，建议按固定顺序看三个指标，而不是直接动手删文件。
- 分区使用率：用 df -h 看各挂载点，重点看站点目录、日志目录、数据库目录所在分区。
- inode 使用率：用 df -i 看，如果 inode 接近 100%，说明小文件太多，删除大文件没有用。
- 目录占用排名：用 du 逐层往下看，先看 /var/log、站点上传目录、缓存目录、数据库数据目录这几个常见位置。
只有先确认是“容量不足”还是“inode 不足”，后续处理方向才不会跑偏。
常见的占用大户有哪些
日志文件
访问日志、错误日志、爬虫日志、应用调试日志，是绝大多数服务器上增长最快的部分。尤其是开启了详细调试级别、或者爬虫请求量较大的站点，日志一天涨几个 GB 并不罕见。
缓存与临时文件
页面缓存、缩略图缓存、模板编译文件、上传过程中的临时分片，如果清理策略缺失，会一直堆在磁盘上。这类文件的特点是单个不大，但数量极多，容易先把 inode 吃掉。
数据库与备份文件
数据库数据文件、二进制日志、本地留存的备份压缩包，往往体积很大。本地备份如果长期保留多份，很容易在不知不觉中占掉大部分空间。
日志轮转该检查什么
日志轮转配置看起来简单，但出问题的情况不少，建议逐项确认：
- 轮转周期是否合理，是否和站点实际日志增长速度匹配；
- 保留份数是否明确，是否存在“保留 30 份但每份都很大”的情况；
- 压缩是否开启，未压缩的旧日志会持续占空间；
- 轮转后写入进程能否正确重新打开文件，避免出现“删了文件但空间没释放”的情况；
- 是否有权限问题导致轮转任务静默失败，日志一直写进同一个文件。
删除一个仍被进程占用的日志文件，磁盘空间不会立刻释放。遇到这种情况，需要让进程重新打开日志文件，或者重启对应服务，才能真正回收空间。
把检查动作固化下来
临时处理完一次，不等于问题解决。更稳妥的做法是把检查变成例行动作：
- 每天固定时间记录一次各分区使用率和 inode 使用率，形成趋势数据；
- 设置阈值提醒，比如使用率超过 80% 或 inode 超过 85% 时发出通知；
- 每周确认一次日志轮转是否按预期执行，检查最近一份日志的修改时间；
- 备份文件保留策略写清楚，本地只留必要份数，其余转移到其他存储；
- 每次上线新功能前，评估它会不会产生新的日志或缓存目录，并补齐清理策略。
这套动作本身不复杂，难点在于坚持。很多站点出问题，并不是不知道该看磁盘，而是没人定期看。
和站点运营的关系
从运营角度看，磁盘空间属于容易被归到“技术那边的事”。但实际影响很直接：页面打不开、访客提交失败、蜘蛛抓取拿到 5xx，损失的都是站点自己的流量和信任。把磁盘检查和内容更新、链接检查放在同一个例行程里，成本并不高，却能挡掉一类很典型的故障。
如果你现在还不确定服务器上哪块空间最紧张，不妨从 df -h 和 df -i 两条命令开始，先看清楚现状，再决定清理和轮转策略。