游戏服务器磁盘写满是导致停机的常见原因，根因在于日志、备份和临时文件的失控增长，处理需分秒必争，预防则依赖监控告警与容量规划的双重保障。
磁盘写满的第一现场：从“卡顿”到“停机”的半小时
那天下午三点,玩家开始反馈进不去游戏，世界频道炸了锅，你登录服务器执行 df -h，看到 /dev/vda1 的 Use% 显示 100%，这时候每多耽误一分钟，玩家流失就多一分，磁盘写满不是瞬间发生的，它有一个从“异常”到“不可用”的演变过程。
最先出现的异常信号
- 数据库连接池爆满：MySQL 或 Redis 无法写入新数据，报错
No space left on device，但读操作可能还正常 - 日志文件戛然而止：应用日志突然停止更新，因为进程尝试写日志时失败
- 玩家操作无响应：游戏内交易、存档、排行榜刷新全部卡住，因为底层存储已满
停机前的黄金抢救窗口
多数情况下，从磁盘使用率达到 95% 到完全写满，大约有 2 到 4 小时缓冲期，这个窗口足够你定位并清理出空间，前提是你知道该看哪里。
执行 df -h 和 df -i 双命令检查，前者看块设备使用率，后者看 inode 是否耗尽。df -h 显示还有空间，但 df -i 显示 inode 用尽，同样会导致无法创建新文件，游戏服务一样会停摆。
游戏服务器磁盘满怎么办：三步根治法
当确认磁盘已满,按以下顺序操作，每步之间间隔不超过 5 分钟。
第一步：定位大文件与可清理目录
du -sh / 2>/dev/null | sort -rh | head -20
这条命令能快速列出根目录下占用最大的前 20 个路径，游戏服务器中，重点排查这几个位置：
/data/logs或/var/log：游戏运行日志、战斗回放日志、跨服战报/backup或/data/backup：数据库备份、配置文件备份、更新包备份/tmp：临时文件、上传缓存、解压中间文件/data/docker：如果用了容器化部署，Docker 的 overlay2 目录可能堆积镜像层
第二步：按优先级清理
先删无害文件，再动业务数据，推荐顺序：
- 清理
/tmp下 3 天前的临时文件：
find /tmp -type f -mtime +3 -delete
- 删除过期备份：保留最近 3 份数据库备份，其余全删
- 清空不再增长的旧日志：
truncate -s 0 /data/logs/game_$(date -d '-7 days' +%Y%m%d).log - 如果以上还不够,考虑停服扩容而非继续删业务数据
第三步：扩容或迁移
清理只是治标,扩容才是治本，云服务器直接控制台操作硬盘扩容，10 到 30 分钟生效，不需要重启实例，扩容后执行 growpart /dev/vda 1 和 resize2fs /dev/vda1 让系统识别新空间。
对于物理机或无法热扩容的场景,迁移数据盘是更稳妥的方案，把 /data 挂载到新购买的大容量云盘上，修改 fstab 确保重启后自动挂载。
磁盘为何会悄悄写满：五个隐蔽元凶
很多运维困惑：明明上周才清理过，怎么又满了？磁盘空间不是被某个大文件一次占满，而是被多个小问题叠加消耗的。
游戏日志的“滚雪球”效应
多数游戏服务器开启了 Debug 级别日志，尤其在版本更新后的头几天，一场大型团战可能产生 数 GB 的战斗日志，包含每个玩家的坐标、技能释放、伤害计算，如果日志框架没有配置滚动策略，单个日志文件能膨胀到几十 GB。
数据库 binlog 与慢查询日志
MySQL 的 binlog 默认可能保留很长时间，在游戏合服、跨服战等高峰期，binlog 增长速度极快。行业共识认为，binlog 保留时长应控制在 24 到 72 小时，超过一周的 binlog 基本没有恢复价值，却白白占用大量磁盘。
更新包与补丁的残留
游戏客户端更新包、热更资源、美术素材压缩包，这些文件在部署后经常被遗忘在服务器上，一次大版本更新可能遗留 5 到 10 GB 的压缩包。
容器镜像与悬空卷
使用 Docker 部署的游戏服，每次构建新镜像都会留下旧的悬空镜像层。docker system df 可以查看具体占用，docker image prune 清理悬空镜像，docker volume prune 清理未被容器引用的数据卷。
核心转储文件
游戏进程崩溃时产生的 core dump 文件，单个文件大小可能达到进程内存的完整快照，一个 8 GB 内存的 game server 进程崩溃，core 文件就可能占用 8 GB，建议在 /etc/security/limits.conf 中设置 core file size
为 0，或启用 systemd 的 Storage=none。
磁盘空间告警监控规则配置：别等满了才后悔
磁盘空间告警 监控规则配置是预防停机的第一道防线，监控的粒度决定了你能提前多久发现风险。
监控项与阈值设定
| 监控项 | 建议阈值 | 告警级别 |
|---|---|---|
| 磁盘使用率 | 80% 警告，90% 严重 | P2 / P1 |
| inode 使用率 | 85% 警告，95% 严重 | P2 / P1 |
| 磁盘写入速率 | 与基线对比，突增 200% 告警 | P2 |
| 日志文件增长速率 | 单日增长超过 5 GB 告警 | P3 |
告警通知的降噪策略
- 工作日白天告警发到企业微信群或钉钉群,夜间告警只发电话和短信
- 同一磁盘的告警做 2 小时静默，避免反复刷屏
- 告警消息中直接附上
df -h的输出和 top 5 大目录路径，让值班人员不用登录就能判断
容量趋势预测
使用 Prometheus + node_exporter 采集磁盘指标，配合 predict_linear 函数预测 24 小时的磁盘使用率，如果预测值超过 90%，自动创建一个工单通知运维预检，这套方案不依赖商业软件，开源组件即可实现。
不同规模团队的磁盘扩容方案对比
游戏团队规模不同,磁盘策略差异很大。小型团队（1 到 3 名运维） 适合简单粗暴的方案，中大型团队需要更精细的管理。
| 方案类型 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 手动清理 + 云盘扩容 | 小型独立游戏，日活低于 5 万 | 成本低，操作简单 | 依赖人工记忆，容易遗漏 |
| 定时任务自动清理 | 有固定维护窗口的中型游戏 | 减少人工干预，规则可沉淀 | 误删风险需要脚本审计 |
| 日志系统集中采集（ELK/Loki） | 多服部署，需要日志检索 | 日志不落本地盘，集中管理 | 需要额外的日志服务器资源 |
| 对象存储归档冷数据 | 老区合并后不再活跃的存档 | 成本极低，释放本地盘压力 | 恢复冷数据需要耗时拉取 |
云服务器磁盘价格与选型参考
据主流云厂商公开定价，高效云盘约 0.5 到 1 元/GB/月，SSD 云盘约 1 到 2 元/GB/月，对象存储的冷存储类约 0.03 到 0.08 元/GB/月，游戏日志和备份这类冷数据，迁移到对象存储是性价比最高的选择。
对于预算有限的中小团队,混合方案值得考虑：热数据放 SSD 云盘，冷日志和备份定时同步到对象存储，本地只保留 3 天的热日志，这样既能保证性能，又能控制成本。
游戏服务器磁盘清理的自动化脚本思路
手动清理总有一天会忘,自动化才是长久之计，一个健壮的清理脚本应该包含以下逻辑：
- 检查当前磁盘使用率,低于 70% 直接跳过清理
- 删除超过保留天数的日志文件,保留最近 3 天
- 删除超过保留份数的数据库备份,保留最近 3 份
- 执行后发送清理报告到运维群,包含释放了多少空间、当前使用率
- 所有删除操作先输出到 dry-run 日志，确认无误后再启用实际删除模式
将脚本放入 crontab，每天凌晨 4 点执行，这个时间点在线玩家最少，即使误删也能在早高峰前发现。
Q&A：磁盘与游戏停机的常见疑问
游戏服务器磁盘扩容后，玩家数据会丢吗？
不会,云盘扩容是底层块存储的扩展，不影响已有数据，扩容完成后执行 resize2fs 让文件系统识别新空间即可。但扩容前务必打快照，防止操作失误导致的意外情况。
为什么磁盘还有空间，游戏却提示写入失败？
可能原因有两个：inode 耗尽，或者某个目录的挂载点配额已满，执行 df -i 检查 inode 使用率，执行 df -h 检查每个挂载点的使用率。多数情况下是 /tmp 或 /var/log 单独分区被占满，而根分区还有空间。
游戏日志可以完全关闭吗？
不建议完全关闭,日志是排查线上问题的重要依据，完全关闭等于瞎子摸象，合理做法是分级记录：Info 级别只记录关键操作，Debug 级别仅在排查问题时临时开启，且开启时间不超过 24 小时，同时配置 logrotate 按大小或日期轮转，单日志文件超过 500 MB 自动切割。
磁盘写满导致停机,本质是容量管理缺失，把监控阈值调低一点，把保留策略写进脚本，把扩容流程提前演练一遍，这个坑就能绕过去。