There are several things to try, some have already been mentioned. We have >4500 targets being polled at the moment and so have had to do all of them.
1) Set lower SNMP timeout and retry options as other people have said 2) Use the Forks: option to create multiple polling threads. This does not work in Windows, I think. You need to set a Forks level appropriate for your system, which depends on the available memory and CPU. 3) Run multiple instances of MRTG by having more than one master.cfg file. We actually do this by using a home-grown scheduler which builds the master.cfg files on the fly and takes care of multithreading, and also temporarily disabled a CFG file if the host/device is down. 4) Get a more powerful polling machine! We use a 2x3GHz Xeon with 6Gb memory. 5) Split your MRTG over multiple servers. You can get an integrated frontend if you use the distributed MRTG feature in routers2 6) Get faster disks. MRTG also bottlenecks on disk IO, so faster disks can help the processing finish sooner. We installed an Adaptec SAS array with multiple spindles. 7) Upgrade MRTG and RRDTool to the latest versions. Apparently they can handle errors and IO better now. Steve ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Lodgen Sent: Friday, 18 April 2008 04:39 To: [email protected] Subject: [mrtg] Large Master Config Vulnerability Hi everyone, I'm running a master config with hundreds of include lines and thousands of targets. This type of setup is vulnerable to errors in config files and/or changes made in the field not being immediately updated within the configs. If there are a few errors or changes out in the field to ports causing them to become 'unpollable', it causes the MRTG polling interval to go over five minutes because it's retrying those interfaces. At the moment, with only about 30 error lines in my log(equating to about 15 interfaces/targets), it's causing MRTG to take 7-9 minutes to complete polling. As this is a very small percentage compared to the total amount of targets being polled, I'm trying to figure out a way to get around this, if possible, or at least to minimize the effects. Is anyone else running a system like this or does anyone have suggestions to try? Thanks in advance for any help! Brad
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
