> 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:[EMAIL PROTECTED] 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
