>From: Carlo Marcelo Arenas Belon [mailto:[EMAIL PROTECTED]
>gmetad hierarchical setups has several areas for efficiency improvement. >this one (doing summaries from partial summaries in the leafs) being one >that was on the "TODO" list as a nice to have for a 3.1 release from what >I recall, and specially because of the increase on the XML sizes with 3.1 >as >you pointed out. > >AFAIK no one was working yet on a fix for that, just because a rewrite of >gmetad in python was the preferred long term solution to the gmetad issues. Ok, that sounds reasonable. I was curious because I accidentally added >2000 clients to a 2GB server. This caused it to continuously swap. I think size of active processes and RRD files in tmpfs exceeded real memory. It looks like we need at least 1GB of memory per 1000 clients reporting. So I was curious if making the processes smaller and faster might help. However, I also know that RRDs all do their detail compression at the same time, so this may not be enough. Obviously we just get more memory or gmetad servers. But I might as well make it more efficient if possible. Since the needed summary is already available on the interactive port, I might see if I can do a hack to pull it from there instead of the too verbose xml port. The python rewrite should consider this also. In fact, I'm not sure it is necessary for gmetad to use 2 ports; the interactive port can already send all the data or a summary. The only reason the xml port is needed is because the connecting one doesn't bother to write a command, right? -twitham ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
