On Nov 9, 2007, at 10:51 PM, richard grevis wrote: > Doug, > > at once per minute polling it should be straightforward to > scale to 6,000 nodes one way or another. > > But I would still cut back on the metrics to only record > the important ones, and be prudent with static numeric metrics > like cpu speed, because they still soak up I/O on the ganglia server. >
ya, certainly. Some of them are just not important to us, too. We'll have a tiered hierarchy as well. > As for synchronicity at once per minute polling, I'm guessing > it won't be much of a problem. Nor will you get data gaps caused > by gmetad threads running out of time to do their work within the > poll interval. > > Could you tell me more about your sucked when poked metrics? > Do you want this to in effect schedule gmond calculations within > the overall job scheduling, so it happens at times you control? > yes, if I understand you correctly. Essentially, there is no collection until you hit the port. Then it collects and spews. That allows us to minimize the jitter because all your nodes are waiting X time all at the same time as opposed to X time, then X time again, then X time again, etc. > - richard Doug Nordwall Unix Administrator EMSL Computer and Network Support Phone: (509)372-6776; Fax: (509)376-0420 ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-general
