最近排查一台新加坡节点的小 VPS，发现硬盘占用总是在慢慢往上爬。WordPress 文章、媒体库、MySQL binlog 都排除之后，最后锁定了一个很容易被忽视的来源：systemd 的 journal 日志。
这类日志不是博客内容，也不是 AMH 面板自己的日志，而是 Debian 系统层的运行日志。像 SSH 登录尝试、定时任务、服务状态变化，都会被写进去。如果服务器挂在公网，日志增长速度往往比想象中快。
我这台机器一开始查到的结果是：
journalctl --disk-usage输出显示：
Archived and active journals take up 440.0M in the file system.对于一台 40G 硬盘的小 VPS 来说，440M 已经没必要了。解决思路也不复杂：给 journald 设置上限，再把旧日志压缩回收。
journal 是什么
先简单说一句，避免混淆。
- amh-access.log、nginx access.log 这类，是面板或网站自己的日志
- journal 是 Debian 系统自己的总日志池，由 systemd-journald 管理
它通常会记录这些内容：
- SSH 登录和爆破尝试
- CRON 定时任务
- 服务启动、重启、报错
- 内核和系统消息
所以你在 auth.log 里看到一堆 Invalid user admin、Invalid user ubuntu 的同时，journal 里通常也会同步增长。
修改 journald 限制大小
直接编辑配置文件：
nano /etc/systemd/journald.conf在 [Journal] 下面加入这几行：
[Journal]
SystemMaxUse=80M
RuntimeMaxUse=30M
SystemMaxFileSize=20M
MaxRetentionSec=7day这几个参数的意思很直白：
- SystemMaxUse=80M：磁盘上的 journal 总占用尽量控制在 80M 左右
- RuntimeMaxUse=30M：运行时日志占用控制在 30M
- SystemMaxFileSize=20M：单个日志文件不要太大
- MaxRetentionSec=7day：最多保留 7 天
这套数值对小内存、小硬盘的 VPS 比较合适。不是绝对标准，但足够实用。
让配置生效
保存后执行：
systemctl restart systemd-journald然后把旧日志清理到目标范围：
journalctl --vacuum-size=80M如果想更激进一点，也可以改成：
journalctl --vacuum-size=50M检查结果
执行：
journalctl --disk-usage我这台机器处理完后的结果是：
Archived and active journals take up 96.0M in the file system.虽然不是精确等于 80M，但这是正常现象。SystemMaxUse 更像一个控制目标，不是硬切到一字不差。只要从几百 MB 降下来了，而且后续不再无限增长，目的就达到了。
再顺手确认一下配置是否写进去了：
grep -Ev '^\s*#|^\s*$' /etc/systemd/journald.conf如果输出类似下面这样，就说明已经生效：
[Journal]
SystemMaxUse=80M
RuntimeMaxUse=30M
SystemMaxFileSize=20M
MaxRetentionSec=7day这一步能解决什么问题
限制 journal 后，至少能解决两件事：
第一，系统日志不再无上限吃盘。
第二，后面再排查磁盘占用时，能把注意力放回真正异常的目录，而不是一直被系统日志干扰。
不过也要说清楚：限制 journal 只是收口，不是治本。
如果你的服务器像我这台一样，公网不断有人扫 SSH 端口，那 auth.log 和 journal 还是会继续写，只是不会再失控。所以更彻底的做法，通常还包括：
- 修改 SSH 默认端口
- 禁止密码登录
- 只允许密钥登录
- 安装 fail2ban
最后
如果你也在用 Debian 11 或类似的 systemd 系统，发现 VPS 磁盘占用总是缓慢上涨，先别急着怀疑网站内容或者数据库。
先看一眼：
journalctl --disk-usage很多时候，问题就藏在这里。
