[image: Inline images 1]
nxlog is essentially stateless, so 3GB RSIZE before restart is clearly a
memory leak. In my case, it was causing OOM-killer to be invoked (on my
Elastic Search node).
There is a slow ramp-up post restart. Will be interesting to observe any
knees over a 48-hour period.
In this instance, nxlog is on Linux (RHEL6.5 x86_64) dealing with a high
volume of logs coming in over TLS (as JSON), streaming to disk files based
on fields in the log, rotating said log files based on size (and calling an
async exec process to compress and suitably archive rotated files into a
NAS), and doing disk buffering on them before passing them, via om_tcp, to
logstash (on another cluster node).
I'm doing very little, if any parsing on this nxlog instance.
Has anyone else seen such behaviour and can spot any commonality?
I might consider hitting it valgrind, but that will be very slow.
--
Cameron Kerr <cameron.kerr...@gmail.com>
See my blog at http://distracted-it.blogspot.co.nz/ (previously
http://humbledown.org/)
Skype me on cameron.kerr.nz
------------------------------------------------------------------------------
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/
_______________________________________________
nxlog-ce-users mailing list
nxlog-ce-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nxlog-ce-users
