>>> On 2/14/2008 at 3:01 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi all:
> 
> On 2/14/08, Martin Knoblauch <[EMAIL PROTECTED]> wrote:
> 
>>   thanks. My tests are still running. The new binaries do not grow anymore. 
> Or at least a lot slower than the original 3.0.4
> 
> Since I can't reproduce this, can someone please explain to me what
> configuration triggers this?  I'll put this in the release notes.
> 

Basically it is just the standard configuration with gmond reporting bytes_in, 
bytes_out, pkts_in, pkts_out metrics.  As part of these metric gathering 
functions, interface names needed to be added to a hash table.  Each time the 
metric function was called and the /proc/net/dev file was parsed, the interface 
names that were found in the file were strdup'ed() and attempted to be added to 
the hash table.  The problem is that the strdup'ed string only needed to be 
added once, however the name was being strdup'ed every time whether it was 
actually added to the hash table or not.  On the attempts when the name already 
existed, the strdup'ed memory was never freed.

Basically, you just have to watch the memory footprint for gmond grow over 
time.  It doesn't happen very fast.

Brad


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to