【Linux】通过MemoryAccounting与MemoryMax精准控制rsyslog内存占用

1. 当你的Linux服务器突然变慢时

最近有台服务器突然变得特别卡，连最简单的命令都要等好几秒才能响应。我习惯性地打开终端输入top命令，发现一个叫rsyslogd的进程居然吃掉了将近40%的内存！这太不正常了，因为正常情况下rsyslogd的内存占用应该在5M左右。

这种情况其实很常见，特别是在长时间运行的服务器上。rsyslogd是Linux系统默认的日志服务，负责收集和存储系统日志。当它开始疯狂占用内存时，通常是因为日志系统出现了问题。我遇到过好几次这种情况，有时候是因为日志文件损坏，有时候是因为日志量突然暴增。

2. 快速诊断rsyslog内存问题的三板斧

2.1 查看实时内存占用

首先用top命令确认问题：

top -o %MEM

这个命令会按内存使用率排序显示进程，rsyslogd如果排在前几位就要注意了。

2.2 检查日志服务状态

查看rsyslog服务的运行状态和最近日志：

journalctl -u rsyslog --since "1 hour ago"

如果看到大量错误信息，特别是关于文件损坏的提示，那问题很可能出在这里。

2.3 验证日志文件完整性

检查系统日志文件的完整性：

journalctl --verify

这个命令会扫描日志文件并报告任何损坏情况。我遇到过几次因为突然断电导致日志文件损坏的情况，都会在这里报错。

3. 彻底解决rsyslog内存问题的两种方案

3.1 应急处理：清理损坏的日志文件

如果发现日志文件损坏，可以这样处理：

# 删除损坏的journal文件 rm -rf /var/log/journal/* # 删除rsyslog的状态文件 rm -f /var/lib/rsyslog/imjournal.state # 重启服务 systemctl restart systemd-journald systemctl restart rsyslog

这个办法能快速解决问题，但只是治标不治本。

3.2 根治方案：用systemd限制内存使用

更可靠的方案是通过systemd的资源控制功能限制rsyslog的内存使用。编辑服务配置文件：

vim /usr/lib/systemd/system/rsyslog.service

在[Service]部分添加以下参数：

MemoryAccounting=yes MemoryHigh=8M MemoryMax=80M

完整配置示例：

[Service] Type=notify EnvironmentFile=-/etc/sysconfig/rsyslog ExecStart=/usr/sbin/rsyslogd -n $SYSLOGD_OPTIONS Restart=on-failure UMask=0066 StandardOutput=null MemoryAccounting=yes MemoryHigh=8M MemoryMax=80M

这三个参数的作用是：

• MemoryAccounting：开启内存统计
• MemoryHigh：软限制，超过后系统会尝试回收内存
• MemoryMax：硬限制，超过后进程会被终止

设置好后重新加载并重启服务：

systemctl daemon-reload systemctl restart rsyslog

4. 深入理解MemoryAccounting和MemoryMax

4.1 内存控制的工作原理

systemd的内存控制是通过Linux内核的cgroups实现的。当设置MemoryAccounting=yes时，systemd会为服务创建专属的cgroup，并在这个cgroup中监控和限制内存使用。

MemoryHigh和MemoryMax的区别很关键：

• 当内存使用超过MemoryHigh时，系统会开始限制进程的内存分配，尝试回收内存，但不会杀死进程
• 当内存使用超过MemoryMax时，系统会直接终止进程（然后根据Restart=配置决定是否重启）

4.2 如何设置合理的限制值

根据经验，rsyslogd的正常内存占用在5M左右，所以：

• MemoryHigh设为8M，给正常波动留出空间
• MemoryMax设为80M，防止内存泄漏导致系统崩溃

对于其他服务，可以用以下方法确定合理值：

1. 观察服务正常运行时的内存使用量
2. 将MemoryHigh设为平均值的1.5倍
3. 将MemoryMax设为MemoryHigh的10倍

5. 高级技巧：预防性配置与监控

5.1 日志轮转配置

为了防止日志文件过大，可以配置日志轮转。编辑rsyslog的配置文件：

vim /etc/rsyslog.conf

添加或修改以下内容：

# 限制单个日志文件大小为50M，最多保留5个 $outchannel log_rotation,/var/log/messages,52428800,/usr/bin/rotate_logs.sh *.info;mail.none;authpriv.none;cron.none :omfile:$log_rotation

创建轮转脚本：

vim /usr/bin/rotate_logs.sh

内容如下：

#!/bin/bash logfile=$1 for i in {4..1}; do [ -f "$logfile.$i" ] && mv "$logfile.$i" "$logfile.$((i+1))" done [ -f "$logfile" ] && mv "$logfile" "$logfile.1" touch "$logfile"

5.2 监控内存使用情况

设置好限制后，可以用以下命令监控效果：

# 查看cgroup内存统计 systemd-cgtop # 查看详细内存使用 cat /sys/fs/cgroup/system.slice/rsyslog.service/memory.current cat /sys/fs/cgroup/system.slice/rsyslog.service/memory.high cat /sys/fs/cgroup/system.slice/rsyslog.service/memory.max

5.3 journald配置优化

如果系统使用journald，还可以优化其配置：

vim /etc/systemd/journald.conf

关键参数：

[Journal] Storage=persistent SystemMaxUse=100M RuntimeMaxUse=50M MaxRetentionSec=1month ForwardToSyslog=no

这样可以限制journald的日志大小，减轻rsyslog的负担。

6. 常见问题排查指南

6.1 限制不生效怎么办

如果设置了内存限制但没效果，检查：

1. 确认systemd版本高于v230（旧版本功能不全）
2. 确保$SYSLOGD_OPTIONS参数存在（有些系统需要这个参数）
3. 检查cgroup是否正确设置：

   systemd-cgls /system.slice/rsyslog.service

6.2 服务频繁被杀死

如果rsyslog频繁重启，可能是：

1. MemoryMax设置过小 - 适当调大
2. 日志量突然激增 - 检查是否有异常日志
3. 系统内存不足 - 用free -h查看整体内存情况

6.3 性能影响评估

内存限制可能会轻微影响日志写入性能，但实测下来：

• 在8M限制下，每秒仍能处理上千条日志
• 对于大多数应用场景完全够用
• 如果确实需要更高性能，可以适当调高MemoryHigh

7. 真实案例：一次完整的问题解决过程

上个月我遇到一个典型案例：某台生产服务器突然变得异常缓慢。按照以下步骤解决了问题：

1. 用top发现rsyslogd占用了1.2G内存
2. journalctl --verify显示有日志文件损坏
3. 清理损坏文件后内存占用降到正常水平
4. 为防止问题复发，配置了内存限制：

   MemoryAccounting=yes MemoryHigh=16M MemoryMax=160M

5. 优化日志轮转配置，限制单个日志文件大小
6. 一周后复查，内存占用稳定在6-8M之间

这个案例说明，结合临时清理和长期预防措施，可以彻底解决rsyslog内存问题。