>>> On 6/25/2008 at 1:18 PM, in message
<[EMAIL PROTECTED]>, "Kirk McDonald"
<[EMAIL PROTECTED]> wrote:
> On Wed, Jun 25, 2008 at 11:48 AM, Brad Nicholes <[EMAIL PROTECTED]> wrote:
>>>>> On 6/25/2008 at 12:13 PM, in message
>> <[EMAIL PROTECTED]>, "Kirk McDonald"
>> <[EMAIL PROTECTED]> wrote:
>>> I have a gmetad which probes a number of gmonds, and each gmond has a
>>> number of hosts associated with it. When I scrape the XML from each of
>>> the gmonds probed by gmetad myself, the TN value for each host looks
>>> good (they average well under 10 seconds). However, when I scrape the
>>> XML from gmetad, the TN values for each host are much higher, enough
>>> so that it begins marking many of the hosts as down. I was wondering
>>> what could cause this to happen.
>>>
>>
>> One possibility is the time difference between the gmond nodes and the 
> gmetad host.  Gmetad will try to normalize all of the timestamps based on its 
> own timestamp.  If there is a big time difference between a gmond node and 
> the gmetad host, the calculation will be skewed.
>>
>> Brad
>>
> 
> I do not think this is the problem. The problem becomes more and less
> apparent if I bring up or shut down gmond on portions of my hosts. If
> all of the gmonds on all of the hosts are up and running, the average
> TN creeps up and large portions of the grid are marked down. (The
> portions marked down appear to be more or less random.) If I shut down
> a significant portion of the gmonds, the average TN on gmetad drops,
> and the hosts are marked up. (That is, ignoring the TN on the machines
> I actually took down, which naturally rises continually.) I would
> expect a calculation error like that to be independent of the number
> of hosts being monitored. There is a definite correlation between
> average TN (as reported by gmetad) and the number of hosts being
> monitored.
> 
> -Kirk

Are all of your nodes in a single cluster?  There may be some latency issues 
with the size of the XML that gmetad has to parse.  If you create multiple 
clusters and reference them through different data sources, gmetad will create 
multiple threads which only have to parse a portion of the whole.  If gmetad is 
on a multiproc box, the multiple threads can take better advantage of the cpus 
rather than parsing everything sequentially.

Brad


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general

Reply via email to