鲁达 大家好，我是不折腾不舒服司机。继上次因为内存容量受限，导致不得不将日志从内存切回硬盘后，还是有点不死心，想再试一把。把之前留给日志的，仅有的10M容量给放大一些。
今天的主角阵容有点庞大，8个选项出列！
SystemMaxUse=
SystemKeepFree=
SystemMaxFileSize=
SystemMaxFiles=
RuntimeMaxUse=
RuntimeKeepFree=
RuntimeMaxFileSize=
RuntimeMaxFiles=
对于保存起来的日志文件会做一个大小上的限制。带System前缀的选项适用于储存在持久化文件系统上的日志文件，准确地说就是 /var/log/journal 。带Runtime前缀的选项使用于保存在易失性内存文件系统中的日志文件，也就是 /run/log/journal 。前者只能在 /var 已经挂载，/var 可写，且路径 /var/log/journal 存在时使用。不然，只会使用后者。这就意味着，在系统启动的早期阶段，如果管理员禁用了持久化日志，就只会使用后者；如果持久化日志已启用，且系统进入完全启动阶段，则会使用前者。
journalctl 和 systemd-journald 会忽略掉所有不以 ".journal" 或 ".journal~" 结尾的文件。这些后缀名都是生成的标准的日志文件的后缀名。所以只有以这些后缀命名的文件，存放在指定路径下的时候，才会在计算当前磁盘使用情况（--disk-usage）的时候，被计算进去。
*MaxUse=
控制了日志最多可用的存储空间。
默认值：10%
上限：4G
*KeepFree=
控制了 systemd-journald 应该留给其它应用的存储空间。
默认值：15%
上限：同样也是4G
如果磁盘快满了，并且这个选项在 systemd-journald 启动的时候，所做的限制已经不满足了，那么极限会被放宽到目前可用空间的百分比。这意味着，如果之前空间是够用的，日志文件也创建好了。但是之后由于种种原因，文件系统被填满了，日志就不会再使用更多的空间，但是也不会移除现有的文件来减少所占的容量。另外，只有存档了的文件会被删除，来减少存储空间的占用。这意味着，实际上，在做了清理（vacuum）操作之后，日志文件所占用的存储空间仍旧会超过SystemMaxUse= 或 RuntimeMaxUse= 所设置的值。
*MaxFileSize=
控制单个日志文件最多能够多大。它影响了通过日志轮转（也就是删除历史存档文件）之后，磁盘空间会多出多少可用空间的颗粒度。默认情况下，这个选项的值是 *MaxUse= 的1/8。那么每个存档文件的大小都是最大可用空间的1/8，如果历史存档文件达到了8个，就达到了 *MaxUse= 的极限，需要删掉最老的存档文件。所以，比较多见的历史存档文件的数量是7个。
以上这些选项在设置值的时候，默认单位是字节，或者可以使用K, M, G, T, P, E 指定容量的单位，分别差1024倍。注意，当日志文件在延展的时候，尺寸的限制是同步施加的，并不需要显式的，通过时间触发的轮转步骤。
*MaxFiles=
控制最多保留多少个日志文件。注意，如果触及这个选项的极限的话，只会删除已存档文件来减少文件的数量；活跃文件仍旧保持原有状态。这意味着，实际上，在清理（vacuum）操作之后，仍旧会有超过这个限制数量的日志文件存在。
默认值：100
那么结合参数来看，RuntimeMaxUse=文件系统容量的10%
所以文件系统的容量是多少呢？
df -h在列表中找到内存日志所在分区 /run 的大小。
总共98M，那么10%就是9.8M了。
目前的使用率只有1%，用起来，用起来。
1天的日志量大概是10M，保留最近3天的日志吧，就30M了。
让我们重复利用之前生成的 /etc/systemd 文件进行配置：
sudo vim /etc/systemd设置完成后，我们重启journald服务：
sudo systemctl restart systemd-journald查看一下 systemd-journald 重启后的状态：
systemctl status 图片中，max的部分已经成功变成30.0M了，完美！
最后，如果要查看当前 的所有配置，可以：
systemd-analyze cat-config systemd之前公司里的服务器，出现过一些莫名的bug，查下来才发现是服务器硬盘满了。那么通过上述几个参数的设置，我们就可以根据机器的配置、自己的需要，进行自定义配置，完美避开存储空间不够所带来的坑了。
如果觉得我的文章对你有帮助，欢迎关注，长按点赞。
你的支持就是我更新最大的动力！下一期，我们不见不散。