服务器缓存占满了怎么办？这波“羊毛”差点让我破产

最近折腾服务器的时候碰到个让人头皮发麻的事儿。

缓存目录把磁盘吃满，仿佛看到了流量账单在向我招手。

事情是这样的，我把 OpenCode 接到了 CPA（这里指代某个结算或计费接口）上，本来想着跑跑数据看看效果，结果在 Pi（树莓派或者是某个低配实例）上跑了一阵子，去后台一看——好家伙，缓存目录直接把磁盘给吃满了！看着那红色的警报提示，我第一反应不是代码写错了，而是这波流量得把我“搞破产”了（开玩笑，但流量费确实肉疼）。

问题现场：缓存为什么会爆？

咱们先别急着重启，先看看这个缓存正常不正常。一般来说，出现这种缓存瞬间暴涨的情况，无非就那么几个原因：

1. 日志开启了 Debug 模式：这是最容易被忽视的。有时候为了排查问题临时开了 Debug，结果忘了关。每一次请求的详细数据都被写到磁盘里，不爆才怪。
2. 临时文件没清理：有些进程在处理大文件时会产生临时文件，如果代码逻辑里没有 try-catch-finally 去确保删除成功，或者是进程非正常退出（比如被 Kill -9 了），这些垃圾文件就会一直残留。
3. 真正的缓存策略失效：如果使用的缓存中间件（比如 Redis、Memcached 甚至本地文件缓存）没有设置过期时间（TTL），或者说 Key 的设计有问题导致无法被覆盖，数据只会进不出。

在我的这个场景里，因为是在 Pi 这种资源受限的环境下跑 OpenCode 和 CPA 的对接，大概率是请求量上来后，频繁的读写操作产生了大量的未回收临时数据，或者是日志没做轮转。

急救方案：先把机器救活

既然已经“要破产”了，那当务之急是止血。如果现在 SSH 还能连上去，赶紧执行以下操作：

1. 快速清理磁盘空间

不要上来就 rm -rf /，先看看是哪个目录最大的。

df -h              # 查看磁盘使用情况
du -h --max-depth=1 /   # 查看根目录下各文件夹大小
``

定位到罪魁祸首目录后（例如 `/var/log` 或 `/tmp`），如果是日志文件，可以直接清空而不是删除（防止进程还在写但找不到文件名）：

![Logrotate 配置示例](/media-load/019f0cd6-27a3-715d-8303-f58752628941)

*开启 Logrotate 日志轮转，按天或大小切割，防止日志无限增长。*

```bash
echo > /var/log/nginx/access.log
``n
#### 2. 检查并清理系统缓存

Linux 系统本身也会缓存文件读写来加速性能，这部分内存是可以释放的：

```bash
sync && echo 3 > /proc/sys/vm/drop_caches
``n
注意：这只是释放 PageCache，不会删掉你的业务数据，但会让系统稍微卡顿一下，因为它需要重新加载缓存。

### 长期优化：治标更要治本

救活了机器，下次别再让它爆了。针对这种“小马拉大车”或者是高并发的缓存场景，我有几个防坑建议：

1.  **开启 Logrotate（日志轮转）**：
    这步非常关键！很多默认安装的服务其实都有配置，但有时候我们手动改了路径就失效了。确保你的日志配置里按天或按大小切割，并且只保留最近 7 天的记录。

2.  **给缓存加个盖子（TTL）**：
    如果你用的是 Redis，务必给 Key 设置 `EX` 过期时间。如果是本地文件缓存，写个定时任务（Cron），每天凌晨清理一下 `tmp` 目录下的过期文件。

```bash
    # 示例：每天清理 /tmp 下超过10天的文件
    0 0 * * * find /tmp -type f -mtime +10 -delete
    ```

3.  **监控预警**：
    别等爆了才知道。装个简单的监控（比如直接用脚本调用 API），当磁盘使用率超过 80% 的时候，给自己发个邮件或者钉钉/飞书通知。

### 总结

这次的“破产危机”虽然虚惊一场，但也提醒了我们：在资源受限的环境（比如各种小内存服务器、Pi 集群）里跑接口对接，**自动化清理机制**比代码本身跑得快更重要。

下次再遇到缓存暴涨，别慌，先查日志轮转，再查临时文件，最后看看是不是中间件没设过期时间。

你的服务器最近还稳吗？欢迎在评论区聊聊你的“续命”经历！