On Wed, 2011-10-05 at 01:44 +0200, Jakub Jankowski wrote:
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?
It definitely seems to be a leak of some kind. If at all possible, running it for some time under valgrind like you did previously would be tremendous. If that's not possible, even generating a core file and running: strings core | sort | uniq -c And try to guess what it could be would probably help to narrow this down. -- Bazsi