Hi,

On Fri, 22 Aug 2014 23:35:54 +1200
Cameron Kerr <cameron.kerr...@gmail.com> wrote:

> nxlog is essentially stateless, so 3GB RSIZE before restart is clearly a
> memory leak.

Yes, that's pretty obvious.

> I might consider hitting it valgrind, but that will be very slow.

Valgrind would be still quicker than trying to prune your conf and create
a reproducible test case.
Below is a set of instructions for valgrind.

Thanks,
Botond

----------------------------------------------------------------------------
Debugging memory leaks

If you see the memory usage climb up and exceed 100Mb this is most likely
a sign of a memory leak. Valgrind is an excellent tool on GNU/Linux to
debug memory leaks. To debug memory leaks with Valgrind, you will need
the following.

Install the dbg package which contains debug symbols, e.g.
nxlog-dbg_2.8.1248_amd64.deb.

Edit nxlog.conf and add the following:
    NoFreeOnExit TRUE

This ensures that modules are not unloaded when NXLog is stopped and
Valgrind can properly resolve backtraces into modules.

Start NXLog under valgrind with the following command. If you have
User set to nxlog in your nxlog.conf then the command must be executed
via su, otherwise valgrind will not be able to create the massif.out file
at the end of the sampling process.
   # cd /tmp
   # su nxlog - -c "valgrind --tool=massif --pages-as-heap=yes /usr/bin/nxlog 
-f"

 Let it run for a while until the valgrind process shows the memory
increase and then interrupt it with control-c. Now you should find a
massif.out.xxxx in the directory.

You can send the massif.out.xxxx along with your bug report or
alternatively you can create a report out of this with the ms_print
command:
   ms_print massif.out.xxx

The output of the ms_print report will contain an ascii chart at the
top that should show the increase of the memory usage. Alternatively you
can send this report along with your bug report.

In the ascii chart you will see the sample number with the highest
memory usage marked with (peak). This should be normally at the end of
the chart, i.e. the last sample. You should scroll down in the output to
this sample and read the backtrace to see where the most memory is
allocated at. 
----------------------------------------------------------------------------

------------------------------------------------------------------------------
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

Reply via email to