Action disabled and that appears to have solved it. I also agree that this means it isn't a leak, but it did look like one at first!
Sorry for any confusion. On 7/24/14, 10:47 AM, David Lang wrote: > disable that action and see if it solves your memory usage. > > for what it's worth, the term "memory leak" doesn't mean any time a > program starts using lots of memory, it's when the program allocates > memory for something and looses track of it so it can never free it. > > In this case, if it is the queue for this action, this is not a leak, > it's rsyslog doing exactly what you told it to and keeping track of > these messages. If the server you are trying to deliver the messages to > comes online, all that memory would end up being freed as the messages > were delivered, showing that it's not a leak. > > David Lang > > On Thu, 24 Jul 2014, Micah Yoder wrote: > >> Update: Got the increased dynafile queue size into prod yesterday. >> Memory leak still exists. However, that action 16, which has the large >> size queue, seems to be (if I'm counting right) going to an unreachable >> elasticsearch server. Looks like that may be the issue .... :/ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
