rsyslogd 占用了 20+ GB (!) 的 RAM - 要收集什么证据？

Question

我有一个运行内核 3.13.0-74 和 32GB RAM 的 Ubuntu 14.04.3 机器，它的特点是一个 rsyslogd 进程变得疯狂：

$ ps -auxww | grep rsyslog
syslog   16212  0.7 64.0 27966168 21070336 ?   Ssl  Jan04 180:31 rsyslogd -c 5 -x

$ free -m
             total       used       free     shared    buffers     cached
Mem:         32142      31863        278        228          9        363
-/+ buffers/cache:      31490        651
Swap:        16383      11937       4446

我知道 ps 的输出不能完全依赖等，但肯定有点高！我还有两台具有相同软件/软件（同时运行）的兄弟机器，并且在这两个兄弟机器上，rsyslogd 的表现更好（每台机器仍然使用大约 3.5GB）。

这是 rsyslogd 7.4.4，我知道在较新版本中修复了内存泄漏。

我的问题：在我急于升级之前，如果可能的话，我想收集一些证据来证明我确实遇到了那个漏洞。我现在已经让 rsyslogd 运行了，但是用不了多久它就会搅动所有的交换，所以需要尽快采取行动......

我收集证据的一件事是atop。这清楚地显示了泄漏开始发生的时间（我不记得当时对盒子做了什么特别的事情）。有趣的是，在内存开始增长的同时，磁盘写入活动急剧下降——尽管它并没有完全停止。文件系统在容量方面很好。

$ atop -r atop_20160117 | grep rsyslogd
  PID  SYSCPU  USRCPU  VGROW  RGROW  RDDSK  WRDSK ST EXC S  CPU CMD            
16212   0.03s   0.06s     0K     0K     0K    96K --   - S   0% rsyslogd       
16212   0.11s   0.22s     0K     0K     0K  1844K --   - S   2% rsyslogd       
16212   0.03s   0.12s     0K     0K     0K   564K --   - S   1% rsyslogd       
16212   0.04s   0.06s     0K     0K     0K    96K --   - S   1% rsyslogd       
16212   0.08s   0.19s     0K     0K     0K  1808K --   - S   1% rsyslogd       
16212   0.04s   0.11s     0K     0K     0K   608K --   - S   1% rsyslogd       
16212   0.02s   0.07s     0K     0K     0K   116K --   - S   0% rsyslogd       
16212   0.06s   0.04s     0K  2640K     0K   144K --   - S   1% rsyslogd       
16212   0.02s   0.02s     0K  1056K     0K     0K --   - S   0% rsyslogd       
16212   0.01s   0.01s     0K   264K     0K     0K --   - S   0% rsyslogd       
16212   0.02s   0.04s     0K  2904K     0K     0K --   - S   0% rsyslogd       
16212   0.02s   0.02s     0K  1056K     0K     0K --   - S   0% rsyslogd       
16212   0.02s   0.00s     0K   264K     0K     0K --   - S   0% rsyslogd       
16212   0.06s   0.09s 75868K  3532K   208K     0K --   - S   1% rsyslogd       
16212   0.02s   0.02s     0K   792K     0K     0K --   - S   0% rsyslogd       
16212   0.01s   0.01s     0K   264K     0K     0K --   - S   0% rsyslogd       
16212   0.05s   0.03s     0K  3168K     0K     0K --   - S   0% rsyslogd       
16212   0.02s   0.02s     0K  1056K     0K     0K --   - S   0% rsyslogd       
16212   0.00s   0.01s     0K   264K     0K     0K --   - S   0% rsyslogd       
16212   0.03s   0.10s     0K  2904K     0K     0K --   - S   1% rsyslogd       
16212   0.02s   0.02s     0K   792K     0K     0K --   - S   0% rsyslogd       
16212   0.00s   0.02s     0K   264K     0K     0K --   - S   0% rsyslogd       
16212   0.04s   0.03s     0K  2904K     0K   160K --   - S   0% rsyslogd       
16212   0.02s   0.02s     0K   792K     0K     0K --   - S   0% rsyslogd       

编辑：这是 Zabbix 为该框提供的可用内存图；1 月 17 日 9:30 左右开始下跌，与atop上面的产量一致。

最终编辑：我不得不重新启动它rsyslogd；它释放了惊人的 20 GB，确认 - 如果有任何疑问 - 它是罪魁祸首：

free -m
             total       used       free     shared    buffers     cached
Mem:         32142      11325      20817        282         56        473
-/+ buffers/cache:      10795      21347
Swap:        16383       5638      10745

唉，仅运行 12 小时后，它现在又回到了 4GB 以上。显然有些不对劲；我将不得不尝试升级路径...

Answer 1

文件/lib/systemd/system/rsyslog.services

[Service]
MemoryAccounting=yes
MemoryCurrent=8192000
MemoryLimit=8192000