>>> 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