2核2G小服务器的磁盘与日志管理：先防满盘，再谈优化

2核2G的小服务器最常见的半夜报警不是 CPU 打满，而是磁盘满了。磁盘一满，数据库写不进、日志写不出、服务起不来，排查时连临时文件都删不干净。所以我的做法是先把“防满盘”当成基线来做，而不是等报警了再救火。

先找到是谁在吃磁盘
第一步永远是定位，而不是盲目删文件。我习惯从根目录逐层看：先看哪个大目录占得多，再进到里面看是日志、缓存还是旧镜像。数据库的数据目录、容器镜像层、包管理缓存和应用日志通常是前四名。定位时要注意区分“文件大”和“文件多”：单个大文件删了见效快，但成千上万个小文件（比如没轮转的日志碎片）更耗 inode，删起来也更慢，排查时两个维度都要看。

日志要设上限，不能无限长
日志失控是最常见的满盘原因。系统日志我用 journald 的思路来管：给它设一个总容量上限，超过就按时间滚动丢弃旧的，而不是让它一直长。应用日志则用 logrotate 做轮转：按大小或按天切分，保留最近几份，旧的压缩归档，过期删除。容器日志也要单独设上限：给每个容器的日志文件设最大尺寸和保留份数，否则一个死循环打日志的服务一夜就能把盘写满。设上限时要留一个原则：线上出问题需要回看的日志至少保留到下一次发布之后，别为了省空间把当天的日志也删了。

定期清理的三类东西
除了日志，还有三类东西值得定期清理。第一是旧的容器镜像和悬空层，更新几次服务后，旧镜像会越攒越多，定期清理未被引用的镜像能腾出不少空间，但清理前要确认当前运行的容器没有依赖它们。第二是包管理和构建缓存，装过依赖、编过镜像的机器上缓存增长很快，定期清一次即可。第三是应用自己的临时文件和上传残留，比如分片上传失败后留下的碎片，要有定时任务去扫，超过一定天数还没被认领的就删掉。

满盘时的应急顺序
万一还是满了，应急也有顺序：先删明确无用的临时文件和已轮转的旧日志，恢复写入能力；再停掉打日志最凶的非核心服务，止住增长；最后才是扩容或迁移数据。不要一上来就删数据库文件或正在写的日志，那样可能把一次磁盘问题变成数据丢失。事后一定要补一条规则：给磁盘使用率设两档报警，超过七成提醒、超过九成紧急处理，并且把“谁在增长”写进日常巡检，而不是只看剩余空间这个数字。

小服务器的磁盘管理说到底就是一句话：所有会增长的东西都要有上限和过期策略。日志、镜像、缓存、临时文件，任何一个没设上限，早晚都会在半夜把你叫起来。