<div dir="ltr">You can find the patch on this branch:<div><br></div><a href="https://github.com/ihrwein/syslog-ng/tree/f/fix-redis-memleak">https://github.com/ihrwein/syslog-ng/tree/f/fix-redis-memleak</a><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-18 3:11 GMT+01:00 Jim Hendrick <span dir="ltr"><<a href="mailto:jrhendri@roadrunner.com" target="_blank">jrhendri@roadrunner.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>I will certainly try.</div><div><br></div><div>Send me a link, and Thanks!</div><div><br></div><div><br></div><div><br></div><div><div style="font-size:9px;color:#575757">Sent from my Verizon Wireless 4G LTE smartphone</div></div><div><div class="h5"><div></div><br><br>-------- Original message --------<br>From: Tibor Benke <<a href="mailto:ihrwein@gmail.com" target="_blank">ihrwein@gmail.com</a>> <br>Date:12/17/2014 5:42 PM (GMT-05:00) <br>To: Syslog-ng users' and developers' mailing list <<a href="mailto:syslog-ng@lists.balabit.hu" target="_blank">syslog-ng@lists.balabit.hu</a>> <br>Cc: <a href="mailto:wernli@in2p3.fr" target="_blank">wernli@in2p3.fr</a>, <a href="mailto:jrhendri@roadrunner.com" target="_blank">jrhendri@roadrunner.com</a> <br>Subject: Re: [syslog-ng] syslog-ng memory usage grows <br><br><div dir="ltr">Hi All,<div><br></div><div>I checked your valgrind log and the redis module and I think the leak is in redis.c:137:</div><div><br></div><div> redisCommand(self->c, "ping"); <br></div><div><br></div><div>This returns a reply object, but it's ignored and never freed. </div><div><br></div><div>If we make a patch on GitHub, could you test it?</div><div><br></div><div>Regards,</div><div>Tibor</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-17 18:36 GMT+01:00 <span dir="ltr"><<a href="mailto:jrhendri@roadrunner.com" target="_blank">jrhendri@roadrunner.com</a>></span>:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Fabien,<br>
<br>
Hope the season is treating you well.<br>
<br>
I ran syslog-ng for 10 minutes (recall, ~7000 EPS incoming) under valgrind and here is the output (attached).<br>
<br>
It looks like there is some sort of leak as the process from yesterday had grown to over 16GB before I stopped it for the valgrind test.<br>
<br>
Thanks for the help (as always).<br>
<br>
And please let me know if I can provide any other data.<br>
<span><font color="#888888"><br>
Jim<br>
</font></span><div><div><br>
<br>
<br>
---- Fabien Wernli <<a href="mailto:wernli@in2p3.fr" target="_blank">wernli@in2p3.fr</a>> wrote:<br>
> Hi Jim,<br>
><br>
> On Tue, Dec 16, 2014 at 01:24:28PM -0500, Jim Hendrick wrote:<br>
> > I'm not sure what I am asking, other than general advice on:<br>
> > - performance using patterndb<br>
><br>
> performance is awesome, I wouldn't worry about it<br>
> although it would help to have some counters on the parsers in the stats<br>
> interface. That bieng said, it could help you to increase the stats level.<br>
><br>
> > - performance using redis destination<br>
><br>
> I can't comment on that one, sorry<br>
><br>
> > - advice on debugging where this memory growth is happening<br>
><br>
> Could you run syslog-ng inside `valgrind --tool=memcheck<br>
> --trace-children=yes --leak-check=yes`?<br>
><br>
> The problem is this will really slow down your instance, but let it run a<br>
> few minutes nevertheless and pastebin the result somewhere.<br>
><br>
> > As a rough measure - I have a syslog-ng process that has been running for<br>
> > less than 3 hours and right now is using 1.52GB of resident memory (shown by<br>
> > "top")<br>
><br>
> I'm suspecting `format-json` to be the source of the leak, or the flow<br>
> control cache. These have been the leak source of our own observations many<br>
> times, although many patches have solved the issues.<br>
><br>
> > (I would rather parse things in syslog-ng, but I *could* do this all using<br>
> > logstash/grok if this proves too much for patterndb at this load)<br>
><br>
> if you're worried about performance, I wouldn't even consider to begin thinking about comparing<br>
> LS/grok to patterndb<br>
><br>
> ______________________________________________________________________________<br>
> Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
> Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
> FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
><br>
</div></div><br>______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
<br></blockquote></div></div>
</div></div></div></blockquote></div></div>