SystemMaxUse限制/var/log/journal/持久化日志磁盘空间，RuntimeMaxUse限制/run/log/journal/tmpfs临时空间；二者互不替代，需正确配置并重载生效，且须关注/run挂载大小与journald内存行为本质。
SystemMaxUse 和 RuntimeMaxUse 到底管什么
SystemMaxUse 控制的是持久化日志（即 /var/log/journal/ 下的文件）占用磁盘空间的上限，只在启用持久化存储时生效；RuntimeMaxUse 管的是运行时日志（/run/log/journal/，重启即丢）的内存/临时空间上限。两者互不覆盖，也不自动 fallback —— 如果你只配了 SystemMaxUse 但没启用持久化，那它根本不会起作用。
- 持久化需确保
/var/log/journal/目录存在且journald有写入权限 - 若
Storage=volatile（默认值之一），SystemMaxUse完全被忽略 -
RuntimeMaxUse的“内存”是误导说法：它限制的是/run下的 tmpfs 空间，本质仍是磁盘配额（只是挂载在内存文件系统上）
为什么配了还是涨个不停
常见错误是改了配置却没触发重载，或配置位置不对。systemd-journald 只读取 /etc/systemd/journald.conf 和 /etc/systemd/journald.conf.d/*.conf，忽略 /run 或 /usr 下的同名文件。
- 修改后必须执行
sudo systemctl kill --signal=SIGHUP systemd-journald（不是systemctl restart，后者会清空运行时日志并可能丢失上下文） - 检查是否真生效：运行
journalctl --disk-usage看当前用量，再用systemctl show --Property=SystemMaxUse,RuntimeMaxUse systemd-journald确认加载值 - 注意单位：配置中写
100M有效，但写100MB会被静默忽略（只接受K/M/G，无B）
RuntimeMaxUse 对内存 RSS 的影响很有限
RuntimeMaxUse 限制的是 /run/log/journal/ 的容量，但它不直接约束 systemd-journald 进程的 RSS 内存。实际观察中，journald 的内存增长更多来自：
- 日志条目未及时刷盘（尤其高频率短消息场景）
-
ForwardToSyslog=yes开启时，内部缓冲区叠加 syslog 转发队列 -
MaxRetentionSec=设得过大，导致索引结构膨胀
单纯调小 RuntimeMaxUse 可能引发频繁轮转和碎片，反而增加 CPU 和内存压力。更有效的做法是搭配 MaxFileSec=1day 和 MaxRetentionSec=7day 控制生命周期，再配合 SystemMaxUse=500M 防止磁盘耗尽。
真正该盯住的其实是 /run/log/journal 的挂载大小
/run 是 tmpfs，默认占内存的 50%，如果宿主机内存大（比如 64G），/run 可达 32G —— 此时即使 RuntimeMaxUse=100M，journald 仍可能缓存大量未落盘数据，表现为 RSS 持续上涨。
- 查看当前
/run大小：findmnt -t tmpfs | grep /run - 临时收紧：
sudo mount -o remount,size=512M /run - 永久修改需在内核启动参数加
systemd.unified_cgroup_hierarchy=1并调整/etc/fstab中tmpfs行的size=选项
journald 的内存行为高度依赖底层存储策略和系统级挂载限制，光调两个 MaxUse 很难治本。最容易被忽略的是：它从不主动释放已分配的内存页，除非日志被轮转、压缩或显式 journalctl --vacuum-size。