I don't think this is exactly correct, each gmond "broadcasts" only its own data, at precompiled intervals based on how much the value has changed and how long since the last broadcast. Setting the deaf mode only makes it not listen to the broadcasts from nodes on the multicast channel that is joined (including itself). The only way to reduce the multicast traffic, besides patching & recompiling the sources, is to set the node as mute. If you do this though, the only way to get its data is to poll it directly over tcp to get the xml dump of the data that it has been listening to and collecting.
Are you sure that ganglia is really the cause of your problem? We have ganglia installed on a cluster with 368 nodes on a single subnet and only see an average of about 68 ganglia multicast packets per second. ~Jason On Wed, 2004-05-05 at 12:58, Paul Henderson wrote: > I don't know if this is simplifying things too much, or just a dumb > reply, but the problem I've seen with ganglia is that every host in the > cluster is listening to every other host in the cluster and broadcasting > all the information, causing a lot of traffic (160 nodes in my cluster). > So what I've done is make 158 nodes "deaf" by editing the gmond.conf > file and setting "deaf on", then restarting the gmond on each. Now only > two nodes are listening to traffic and broadcasting all data, and the > other 158 nodes are just sending out their own data. This reduced the > traffic considerably. My network folks are happier. > > James Casbon wrote: > > >Hi, > > > >So I have been using ganglia without problems for a while, and it seems > >excellent. The other day the network administrator calls up and asks why we > >are using so much (15%) of his bandwidth stating that he noticed some weird > >traffic that was flatlining and therefore didn't look like normal network > >usage. > > > >Now, I traced this to ganglia's multicast, which I have had to disable. But > >I > >have a few questions: > > > >* Is is normal to produce this much traffic? Can I set the interval on > >broadcasts to be much higher or something? > > > >* Now, I'm pretty sure most of the traffic is coming from the workstations, > >as > >most of the cluster is behind another NIC connected to our server and not > >able to even see the internet. Multicast traffic wont be copied over the > >NIC > >since there is no NAT for the cluster, right? > > > >* So that leaves the workstations. A firewall box does NAT for the > >workstations, but both NICs of the firewall are connected to the same > >switch > >(run by the network administrator), with one connecting a true internet IP > >and the other on our local subnet. Now, I tried dropping the multicast > >packets using iptables, but no log messages show up with dropped packets. > >So > >I started thinking, maybe the switch is routing the multicast packets before > >they even get to the firewall, so its not even possible to drop them there. > >Is that the case? Or can I filter them using iptables, and if so what is > >the > >correct line to include in the NAT script (I use the iptables script found at > >http://en.tldp.org/HOWTO/IP-Masquerade-HOWTO/stronger-firewall-examples.html#RC.FIREWALL-2.4.X-STRONGER)? > > > >I'm still getting my head round this multicast thing, so apologies if this > >is > >obvious. > > > >Many thanks, > >James > > > > > >------------------------------------------------------- > >This SF.Net email is sponsored by: Oracle 10g > >Get certified on the hottest thing ever to hit the market... Oracle 10g. > >Take an Oracle 10g class now, and we'll give you the exam FREE. > >http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click > >_______________________________________________ > >Ganglia-general mailing list > >[email protected] > >https://lists.sourceforge.net/lists/listinfo/ganglia-general > > > > -- /------------------------------------------------------------------\ | Jason A. Smith Email: [EMAIL PROTECTED] | | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 | | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 | | Upton, NY 11973-5000 | \------------------------------------------------------------------/
