On Mon, 3 Oct 2011 14:34:13 +0200 (CEST), Jakub Jankowski wrote:
As strange as it was, it seems really fixed with git HEAD. Using dist tarball Gergely provided (thanks again), I've built 70fa96f33c89ce2bb10d10aaa7ba0492764a441c and ran my tests. Results are comforting:
$ grep -A 6 'LEAK SUMMARY' s3.3.1-70fa96f33c89ce2bb10d10aaa7ba0492764a441c-const.log ==28094== LEAK SUMMARY: ==28094== definitely lost: 101 bytes in 2 blocks ==28094== indirectly lost: 1,010 bytes in 21 blocks ==28094== possibly lost: 12,919 bytes in 106 blocks ==28094== still reachable: 76,628 bytes in 3,275 blocks ==28094== suppressed: 0 bytes in 0 blocks ==28094== $ grep -A 6 'LEAK SUMMARY' s3.3.1-70fa96f33c89ce2bb10d10aaa7ba0492764a441c-random.log ==30031== LEAK SUMMARY: ==30031== definitely lost: 101 bytes in 2 blocks ==30031== indirectly lost: 1,010 bytes in 21 blocks ==30031== possibly lost: 12,919 bytes in 106 blocks ==30031== still reachable: 76,628 bytes in 3,275 blocks ==30031== suppressed: 0 bytes in 0 blocks ==30031== $
It behaves the same no matter what files it creates. I'll soon see how it's doing on production systems. Thanks for the fix and help.
I think I spoke too soon. :-/ See attached cacti graph. This is basically an output of awk '/VmRSS:/ { $print $2*1024 }' /proc/$(cat /var/run/syslog-ng.pid)/status on git head ("3.3.1" ATM). There must be something else going on; any hints on how to diagnose this? Regards, -- Jakub Jankowski|shasta@toxcorp.com|http://toxcorp.com/ GPG: FCBF F03D 9ADB B768 8B92 BB52 0341 9037 A875 942D
