rsyslogdは20GB（！）以上のRAMを使用します。収集する証拠は何ですか？

カーネル3.13.0-74と32 GBの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の出力が背中を完全に信頼できないことを知っていますが、確かに少し高いです！また、同じソフトウェア（同じ時間に実行）を使用する2つの兄弟コンピュータがあり、両方の兄弟コンピュータで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がボックスに提供した利用可能なメモリのグラフです。atop上記の出力と一致して1月17日9時30分頃に落ち始めました。

最終編集：再起動する必要がありrsyslogd、20GBという膨大なスペースが確保されて疑わしい場合、これが犯人であることを確認しました。

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を超えました。確かに何か問題があるようです。アップグレードパスを試してみる必要があるようです...