Hi Jesse:
Since I didn't hear any fuzz about this, I checked it into trunk r973.
Cheers,
Bernard
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/
>>> On 2/14/2008 at 3:31 PM, in message
<[EMAIL PROTECTED]>, "Bernard Li"
<[EMAIL PROTECTED]> wrote:
> Hi Brad:
>
> On 2/14/08, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>
>> Basically it is just the standard configuration with gmond reporting
> bytes_in, bytes_out, pkts_in, pkts_out metrics. As
Hi Vaibhav:
On 2/14/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Thanks a lot for the solution. Should I wait for a day or two for a
> release with patches or procedd to aplly the patches and rebuild gmond.
I just posted a beta for 3.0.7 with the patches. Please see the email
I just sen
Hi guys:
Since SourceForge's shell access is down, I can't upload the snapshots
to ganglia.info, so I put them here:
http://therealms.org/oss/ganglia/testing/
The following issues are fixed from the last (3.0.6) release:
- [web] Host view metric graph's "now (x.xx)" number is always 0.00
- [web
Hi Brad:
On 2/14/08, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> 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 tim
>>> 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
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
Hi Brad,
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
Cheers
Martin
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
- Or
I reverted the patch that I had originally in trunk and have committed
Martin's patch to both trunk and the monitor-core-3.0 branch. There has been
some testing done already, but it would probably be good to test a bit more.
Brad
>>> On 2/14/2008 at 11:50 AM, in message
<[EMAIL PROTECTED]>,
I have also diagnosed the same problem. It seems me that memory allocated
by strndup calls are not freed in libmetrics/linux/metric.h I was in a
process of testing the code after putting some free() calls. Since now you
have informed that It has been allready fixed I wish to see the fixes in
3.0.7.
On Thu, Feb 14, 2008 at 10:57:57AM -0800, Bernard Li wrote:
> I just checked in my patches, so please go ahead and do your thing.
r970 | carenas | 2008-02-14 11:16:19 -0800 (Thu, 14 Feb 2008) | 1 line
web: code style fixes to minimize spurious differences with trunk
Carlo
--
Hi Carlo:
On 2/13/08, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote:
> to avoid noise would like to add later a "formatting" patch to 3.0.6 which
> should be kept separated from the one you are going to commit and that could
> be
> used independently for anyone which would like to cherr
Hi guys:
On 2/14/08, Brad Nicholes <[EMAIL PROTECTED]> wrote:
> It doesn't really matter to me which patch we use. The most important
> thing is consistency. If you feel like your patch is more complete, I would
> suggest that you drop it into trunk first and then backport it into the 3.0
Hi Ulf:
On 2/13/08, Ulf <[EMAIL PROTECTED]> wrote:
> you know, my never ending wish is the integration of
> http://wtf.ath.cx/ganglia-dev/custom_graph_addon.tar.gz . The
> integration with 3.0.6 still works fine.
The 3.0.x branch is frozen for new features -- it is a maintenance
branch for se
Martin,
It doesn't really matter to me which patch we use. The most important
thing is consistency. If you feel like your patch is more complete, I would
suggest that you drop it into trunk first and then backport it into the 3.0.x
branch. We probably need to look at the other platforms a
Brad,
definitely, one of the two patches should go into 3.0.X. Both seem to do the
same. See other comments elsewhere.
Cheers
Martin
--
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
- Original Messag
Hi Brad,
as far as I can see, both patches achieve the same result. I like mine a bit
more, because it concentrates the whole allocation/freeing of the temporary
"devname" inside the hash_lookup routine. Less code, less chance to forget it
again. But the result counts.
I can now attest, that
Here is the patch diff in SVN
http://ganglia.svn.sourceforge.net/viewvc/ganglia/trunk/monitor-core/libmetrics/linux/metrics.c?r1=860&r2=933
I haven't looked at any of the other platforms besides linux. Do we have the
same problem there?
Brad
>>> On 2/14/2008 at 6:29 AM, in message
<[EMAI
This was already fixed in trunk about a week ago along with several other
memory leaks that were more specific to 3.1 rather than 3.0. We should
probably just backport the trunk patch to 3.0.7 to maintain consistency.
Brad
>>> On 2/14/2008 at 6:29 AM, in message
<[EMAIL PROTECTED]>, Martin
Hi,
maybe attached patch (based on 3.0.4) can fix the leak. The daemon runs and
reports metrics. It is of course to early to say.
When looking at the linux metrics file, I just realized hom much code
duplication there is. Basically all funtion-groups that grok the same
/proc/xxx files should
Hi,
after looking at one of my employerss customers installations, it definitely
seems that metrics-collecting/non-mute "gmond"s are growing (substantially)
over time. Pure listeners seem to be unaffected.
If I remember correctly, Kumars valgrind traces found that "strndup" might
allocate la
21 matches
Mail list logo
