[mrtg] Re: MRTG Limitation

[Rich Adamson]

> Am planning to use MRTG to monitor errors, crc and discards on Cat2900 per 
> interface.  Now we have more than 150 24-port switches on the whole 
> network.  Can MRTG scale to this large number of objects to monitor? 
> Approx more than 3600 objects.  Thanks.
 
The stock implementation of mrtg polls device ports in a sequential manner,
requesting two oid's in each packet, waiting for a response, processes the 
response and then moves on to the second port/interface to be polled.

The snmp request (poll) typically includes two oid strings that can vary 
in size (string length), however a poll packet will be around 110 bytes in 
length (mib2 octets in & out) while the response to the poll will typically 
be about 115 bytes (depending upon the exact data being polled).

If the 3600 objects to be polled are all remote (across a WAN), the
round trip propagation delay will be the limiting factor as to how many
objects can actually be polled within a given timeframe. Assuming each
remote location had a 100 millisecond propagation delay, 3600 objects
would require a _minimum_ of 360 seconds (or 6 minutes) to complete.
That does not include any delays associated with processing and logging
the data that was returned, etc.

If the 3600 objects are accessible at ethernet speed, the delay will
be much shorter and most likely directly related to the snmp processing
speed of the device being polled. An older C2900 switch will not respond
to an snmp poll anywhere near as quick as a new Cisco router as an
example.  Assuming all devices responded in 20 milliseconds, the polling
cycle could complete in a minimum of 72 seconds (plus data processing 
time).

Since the stock mrtg implementation relies on perl, the loading/unloading
of it can consume a fair amount of processing overhead not to mention the
overhead involved with processing each of the 3600 poll/responses. How
quick the mrtg system processes the returned data is directly related to
the OS in use (along with it's resources such as disk speed and processor
speed), keeping in mind that every response requires mrtg to essentially 
move the *.log file to *.old, creating a new *.log file adding the 
response to the beginning of the file, and adding the history entries to 
the *.log file after that, etc, etc. It's not uncommon to see a delay of 
10-to-30 milliseconds between polls (your mileage will vary for all of 
the reasons noted). 

Therefore making a short story very long, if all 3600 objects are local
and the mrtg system is not all that efficient, each poll _could_ consume
roughly 30-to-50 milliseconds, or 108 to 180 seconds per five-minute
polling cycle. If all were remote, elapsed time could be from about 3
minutes to more than 6 minutes to complete. Obviously 6 minutes is much
longer than the stock 5 minute polling interval, therefore the polling
cycle would never complete.

If you configured mrtg to run as two completely independent polling
processes (each with one-half the interfaces to be polled), the elapsed
time for the polling cycle would be slightly more than half of those
times noted. If the mrtg machine is running other applications such
as Apache, IIS, etc, the individual polling times will go up.

Taking that one step further and assuming you are given a discarded
(slow) Intel workstation to use for a stock mrtg implementation, the
snmp traffic will consume about 2400-to-4000 bytes/second of bandwidth
(or about .1% to .3% of a 10-meg ethernet). A faster system, etc,
obviously increases the bandwidth consumption, however the limits will
still be end-to-end propagation delay and system processing overhead.

Can mrtg scale to 3600 objects? maybe, depending upon your exact 
configuration, network, etc. The high-end limit for a stock mrtg will 
likely be associated with the processing overhead of perl/snmp, the 
log files, and what else is running on the system.  Cutting the polling 
cycle to one or two minutes (instead of the default five minutes) will 
not scale at all.

Rich

--
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