I was using an older version and after updating it has definitely improved the speed. I also changed the other options everyone mentioned.
It still doesn't seem to have answered the vulnerability that changes out in the field bring if the configs aren't updated immediately. I just wish there was some way I could make the system be more fault-tolerant instead of having to make more smaller configs to get rid of it. I'll keep working on it and if I find anything, I'll report back here. =) Thanks for the help. Brad On Thu, Apr 17, 2008 at 12:38 PM, Daniel J McDonald < [EMAIL PROTECTED]> wrote: > On Thu, 2008-04-17 at 11:39 -0500, Brad Lodgen wrote: > > Hi everyone, > > > > I'm running a master config with hundreds of include lines and > > thousands of targets. > > Ditto. > > > 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. > > What version are you running? Dead host detection got noticeably better > in 2.15.1 > > > > 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. > > How many forks are you running? More forks will help. I also limit > retries. e.g.: > Target[random-router.example.com.cpu1]: > > cpmCPUTotal5secRev.1&cpmCPUTotal1minRev.1:[EMAIL PROTECTED]: > :2:1:1:3 > > ::2:1:1 is read "try twice. Wait 1 second after the first attempt, and > add a second for each subsequent attempt". So, I have a maximum of 3 > seconds. The default is 3 polls with a 10 second timer, or 30 seconds. > > > > 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? > > Yes. Current code. Plentiful forks. Short timeouts. > > That doesn't affect one other problem I have. If I get an Include: line > without the file existing (it happens, particularly since I generate the > master file from a script reading a database...) then the whole thing > just stops. I would like a "try to include" option that looks for the > file, but if it can't find it will still process the other 471 include > files... > > I know, I know, I should just write it and submit the code.... Maybe in > August I might have a few days... > > -- > Daniel J McDonald, CCIE #2495, CISSP #78281, CNX > Austin Energy > http://www.austinenergy.com > > _______________________________________________ > mrtg mailing list > [email protected] > https://lists.oetiker.ch/cgi-bin/listinfo/mrtg >
_______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
