[rtg] Traffic is wrapping

[bill fumerola]

On Tue, Apr 08, 2008 at 12:29:49AM -0500, Bryan Wann wrote:
> I've been polling a few dozen fully loaded 6509s and 6513s (336-528 
> interfaces each) on a dual x dual core Xeon system. I'm just barely able 
> to keep it around 240 seconds (300 sec intervals) by only measuring 
> in/outOctets, in/outErrors and discards.  It seems in my case the limiting 
> factor is the sheer speed getting data from the switches (lots of sup1A 
> and sup2s), as I get the same runtimes even with MySQL inserts disabled. 
> Past 40-50 threads I don't see any more improvement.

if you're getting the same runtimes with no database action you could
have devices taking a long time to respond, dead/inaccurate targets,
etc.

given the router/switch hardware is from a decade ago and those processors
are weak, increasing the amount of threads may actually make things
worse. cisco's scheduler doesn't like being hit w/ 50 SNMP requests with
one PDU each in them all at the same time.

> I'm actually writing a script to chop up targets.cfg into seperate config 
> files, one for octet counters, errors/discards, packets/s, so I can see 
> how I fare with three distinct rtgpoller processes.  If anything this'll 
> let me poll only errors on longer intervals.  Next up will be rolling up 
> my data as well, I really don't need five minute counters for months and 
> months.

this is one way of getting around the limitations in the way targets,
hosts, and oids are handled in the poller in CVS.

> Thus far I'm pretty impressed, RTG has been the only poller I've been able 
> to handle this sort of density with.  I've made mincemeat out of Cacti and 
> Torrus, constantly reading/writing to thousands of RRD files was getting 
> pretty expensive and didn't let me cover nearly as many switches.

there are ways of tuning those systems as well, but that's for another
list.

unless i'm hallucinating, in one mode, cacti actually uses an ancient
version of rtg as its poller. if that's still the case (they may have
moved towards php snmp only), it'd be nice to get the developers together
and work towards a common goal. cacti dealing with targets, graphing,
configuration, rrds (support for which could be added to rtg) and rtg
being the engine and possibly porting some of the display code over to
cacti.

that all being said, this rtg non-contributor found it difficult to get
the rtg developer to even notice patches, bugs, etc. the situation is
better now than it was back in 2005, but not by much.

-- bill