[rtg] Traffic is wrapping

[Bryan Wann]

On Tue, 8 Apr 2008, Ryan DiRocco wrote:

> We're polling a few hundred devices and over 4000 total ports. The only
> performance / scalability issues we've run into thus far is a memory leak on
> the rehashing of the targets.
>
> We're running on a C2D 6550, 4gb ram.
>
> We actually 'roll up' the data out of the main RTG database and pull it into
> separate databases so that eliminates the 'growth' problems of the rtg
> tables and the requirements for heavy repair / optimizes.
>
> We also then summarize the data into hourly figures, daily figures in / out,
> etc. It helps keep down table size for highly 'active' data.

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.

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.

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.



Met vriendelijke groet/kind regards,
bryan