[mrtg] Re: MRTG Sizing Issues?

[Rich Adamson]

Memory is always a consideration, but probably not as
bad as one might think. I've not actually looked at how
the mrtg/perl routines are written, but would have to
guess the majority of implementations (including Win32)
use libraries/dll's that are loaded once, and used by
each instance of mrtg. Therefore, the amount of memory
actually consumed is not equal to what's used by one
instance times the number of instances. It's less.

If one configures mrtg for two/three/four instances and
spread the long response time devices over those instances
carefully (attempting to balance the elapsed time for each
instance's complete polling cycle), one should be able
to poll several thousand devices within the standard
five minute polling cycle. Lots of other things to consider
when approaching that level though. (Somewhere along that
path a network manager is going to probably question the
value of those snmp polls vs utilization.)

If one thinks about the amount of real processor work that
needs to be done "per device" within a five minute cycle,
one should be able to balance the number of instances, etc,
rather easily. Certainly isn't rocket science.

------------------------
> Million thanks to your tips.
> 
> I also think of memory issue if one mrtg is spawned
> for each device at extreme case. This way can avoid
> the snmp timeout issues of some devices and ease the
> configuration change for each device.
> 
> However, the memory cost may be very expensive. In my
> observation, it takes 7Mbyte per perl run. It would
> accumulate to rocket high lumpsum when hundreds of
> devices to be managed.
> 
> 
> > > number of devices/interfaces mrtg can work with?
> > 
> > The upper limit on number of devices is either
> > limited
> > by cpu or poll-response delay.
> >  
> > > As far as I know, mrtg is a single process perl
> > > script.
> > > Therefore, I guess I can run multi-instance of
> > mrtg so
> > > as to take advantge of multi-cpu to catch up the
> > 5-min
> > > polling when there are large number of
> > > devices/interfaces.
> > 
> > Others have run multiple instances before, no
> > problem.
> >  
> > > However, I am not 100% sure if this works and if
> > there
> > > be any other limitations in large scale
> > deployment.
> > 
> > Two issues: a) cycles consumed by polling, and, b)
> > cycles
> > consumed building the graphics from the polled data.
> > 
> > The default mrtg configuration is essentially a
> > single-
> > threaded app whose poll completion time is highly
> > dependent
> > on the round-trip poll-response time (including
> > propagation
> > delays, equipment response time, etc). If all
> > devices to
> > be polled responded in exactly 100 milliseconds
> > (WAN), the
> > max would be roughly 3,000 devices. However if all
> > responded in 10 milliseconds (LAN), the max would be
> > about 30,000 devices. (Obviously, lots of
> > assumptions
> > in that basic calculation.)
> > 
> > Changing the mrtg config so as to run two
> > independent
> > polling processes would almost double those numbers.
> > 
> > So, the bottom line is that throwing a multi-cpu
> > motherboard
> > and/or high speed disk at mrtg isn't going to have
> > much 
> > impact if the poll-response times are relatively
> > high.


--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi