### [VPS journald日志占满磁盘怎么办？先分清保留策略、持久化与安全清理](https://www.jiyueip.com/article/13359)

**Published:** 2026-07-30T04:43:59

**Author:** 斑斓助理

**Excerpt:** VPS磁盘突然被systemd-journald日志占满时，先判断日志写在内存还是磁盘，再区分临时清理、长期保留策略和异常刷屏。本文给出journalctl盘点、轮转、vacuum、journald.conf配置与复核步骤。

VPS 的 `/var/log` 变大，不一定是网站访问日志。启用持久化日志后，`systemd-journald` 会把系统、服务和内核消息写入 journal 文件；当服务反复报错或没有设置容量上限时，磁盘可能先被日志吃满。处理这类问题的顺序应是“确认占用位置—保留一份现场—临时释放空间—设置上限—验证是否复发”，不要直接删除整个日志目录。

## 先确认：到底是 journald 占满了磁盘吗

先看文件系统和 inode，再看 journal 自己的统计：

```
df -hT
df -ih
journalctl --disk-usage
journalctl --verify
```

`journalctl --disk-usage` 只统计 journal 文件；如果它显示的容量很小，而 `df` 仍接近 100%，应继续检查 Nginx、Docker 日志、应用目录和“已删除但仍被进程打开”的文件。可以用下面的命令限定在同一文件系统内盘点：

```
sudo du -xhd1 /var/log /run/log 2>/dev/null | sort -h
sudo lsof +L1
```

journal 可能位于 `/run/log/journal`（易失、重启后清空）或 `/var/log/journal`（持久化）。先确定路径，才能判断该改运行时上限还是持久化上限。

## 磁盘告急时，先轮转再按大小清理

如果已经影响到数据库、SSH 或网站写入，先保存最近一段日志和当前时间，然后让 journald 封存当前文件，再清理旧文件：

```
sudo journalctl --rotate
sudo journalctl --vacuum-size=500M
sudo journalctl --disk-usage
```

`--vacuum-size` 只删除归档文件，不会按指定大小截断正在写入的当前文件。也可以按时间清理，例如：

```
sudo journalctl --rotate
sudo journalctl --vacuum-time=7d
```

保留 7 天或 500 MB 只是示例，生产环境要结合故障追溯周期、磁盘容量和合规要求决定。若磁盘已经没有空间，清理前不要运行会产生大量临时文件的打包或全文检索命令。

## 用 journald.conf 设置长期上限

临时 vacuum 不能阻止下一次日志刷屏。编辑 `/etc/systemd/journald.conf`，按需设置持久化、容量和保留时间：

```
[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day
RuntimeMaxUse=200M
RateLimitIntervalSec=30s
RateLimitBurst=10000
```

`SystemMaxUse` 限制持久化 journal 总量，`SystemKeepFree` 为文件系统保留空间，`RuntimeMaxUse` 针对 `/run` 下的运行时日志，`MaxRetentionSec` 是时间上限。容量值不能脱离 VPS 磁盘大小照抄；例如 10 GB 系统盘不适合同时设置过大的日志和缓存预算。

保存后重启 journald 读取配置：

```
sudo systemctl restart systemd-journald
systemctl is-active systemd-journald
journalctl --disk-usage
systemctl show systemd-journald -p FragmentPath -p DropInPaths
```

如果发行版提供了 `/etc/systemd/journald.conf.d/`，也可以将站点策略放进独立的 `limits.conf`，便于审计和回滚；修改前先记录原文件内容。

## 日志突然暴涨，别只调大上限

容量上限解决的是“占多少”，不解决“为什么一直写”。查看最近错误最多的服务：

```
sudo journalctl -p warning..alert --since "1 hour ago" --no-pager
sudo journalctl --since "1 hour ago" -o short-iso --no-pager | tail -n 200
sudo journalctl -u nginx --since "1 hour ago" --no-pager
```

若同一错误每秒重复，优先修复服务配置、DNS、证书、依赖或重启循环；不要为了安静而关闭所有日志。systemd 服务依赖导致的重复失败可参考[VPS systemd服务依赖启动失败的排查方法](https://www.jiyueip.com/article/13352)，应用文件日志轮转问题则可对照[VPS Logrotate不生效的排查清单](https://www.jiyueip.com/article/13271)。

## 发布前后的验收清单

-   再次执行 `df -hT`、`df -ih`，确认释放的是目标文件系统而不是临时挂载。
-   用 `journalctl --disk-usage` 记录当前容量，等待一个轮转周期后复查。
-   用 `journalctl -u 目标服务 --since ...` 确认关键服务仍能写入和查询日志。
-   检查 `SystemMaxUse`、`SystemKeepFree` 与磁盘实际大小是否匹配，并把配置纳入备份。

如果清理后容量很快再次上升，问题通常在异常日志源、重启风暴或磁盘上其他目录；回到占用盘点，不要反复执行 vacuum 代替根因修复。

## 常见问题

**journalctl –vacuum-size 没有明显释放空间，为什么？**  
它只删除归档文件；先执行 `journalctl --rotate`，并确认真正占用磁盘的是 journal，而不是应用日志或已删除未释放文件。

**把 Storage 改成 volatile 能解决吗？**  
它会把日志放到运行时目录，重启后不保留，不能替代容量治理。需要审计或故障追溯时，不应为了省磁盘而永久关闭持久化。

**能直接删除 /var/log/journal 下的文件吗？**  
不建议。优先使用 journalctl 的 rotate/vacuum，让 journald 自己维护索引；直接删除可能造成查询缺口，极端情况下还会与正在写入的文件竞争。

**RateLimitIntervalSec 和 RateLimitBurst 应该设多大？**  
没有通用值。先定位刷屏服务，再按业务允许的日志粒度设置；限制过低会丢失故障线索，限制过高则无法抑制异常循环。

**Tags:** Linux服务器, Ubuntu服务器, VPS, VPS监控, 云服务器

**Categories:** 行业洞察

---