[mrtg] Re: best practice

Greg.Volk at edwardjones.com Greg.Volk at edwardjones.com
Thu Jan 31 06:18:45 MET 2002



I too am using multiple config files. I have 1539 targets
across 52 config files on one machine. I run in daemon 
mode and each config file is a single device. The only
downside to running 52 daemons is memory - I have 256megs
in this box (AMD-1800 duallie) and, on average, 30megs of 
swap is always allocated. I suspect that another 256meg 
stick would satisify the situation.

I suppose I could go back to cron'ing 10 mrtg instances
every minute and probably remedy the memory problem - in
the short term, but I've written some scripts with 
autoconfiguration in mind and they are married to daemon 
mode to a certain degree. Another $100 stick of memory 
would be _much_ easier to implement than a script 
rewrite. ;)

Right now the performance is quite impressive, that is 
when I hit the overview page for one of my big switches 
with ~200 interfaces in it, 14all kicks off and manages to
pop out all 200 index graphs in about 15 seconds.


Additional reasons for using many config files are:

14all.cgi has performance problems when having to sift 
through big (greater than 500k) config files. I used to 
have everything in a 1.6meg config file, and 14all would
just eat the box alive when I did a &dir= query against 
the config file. It would bring that AMD-1800 to it's 
knees and leave a user waiting 7-9 minutes for a 75 graph
index.

Polling robustness - Back when I was using one large 
config, if one of my big switches went unreachable 
(hopefully a scheduled outage :| ) mrtg would get hung up
waiting for the polls to that switch to time out and
never complete an entire Target sweep. The result was 
that I would loose all of the poll data for all the targets 
in the config file until that particular switch was back 
on-line and responding. Not good. I tried fixing this with 
"Forks: 50" but that didn't help. I don't know how mrtg 
forking works (one target per fork?) but still, the vast 
majority of the Targets would not be getting queried if a 
many-targeted device was unreachable.


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



More information about the mrtg mailing list