[mrtg] Re: forking details

[Adam Augustine]

There are a few things you can do to mitigate this problem.

MRTG queries in the order that targets are listed, so putting the big
targets at the end of the config file would assure that the smaller targets
get updated first, then it isn't as big a deal if you are waiting around for
the larger ones.

You could also lower the timeout on a global and/or per target basis, which
would also mitigate the problem. See the "SnmpOptions" and "Extended Host
Name Syntax" sections at
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/reference.html.

But really, I would crank the forks up to 10 or 20 or more. I don't think
the performance impact is going to be nearly bad as you think. I have my
forks set to 10 for a few hundred targets and running on a PII 333Mhz 128MB
RAM. The big impact for me is when the graphs are drawn (since I am using
MRTG w/o RRDTool), and even that isn't too bad. You wouldn't have that
problem since you are doing the 14all.cgi thing. The SNMP queries are just
waiting for responses after all, and that isn't consuming much RAM and
almost no CPU. I would suggest giving it a try and if it thrashes, just kill
the process and re-start it with a lower Forks setting. You wouldn't lose
more data than you are already losing.

You do raise a good point though, I haven't seen any discussion on the list
about how the Forks option works, and it would be very interesting to hear
what Tobi or someone else near to the code says about it.

Let us know how that works.

Adam


> -----Original Message-----
> From: Greg.Volk at edwardjones.com [mailto:Greg.Volk at edwardjones.com]
> Sent: Wednesday, November 14, 2001 12:06 PM
> To: mrtg at list.ee.ethz.ch
> Subject: [mrtg] Re: forking details
> 
> 
> 
> > There's no reason why you can't run multiple mrtg processes 
> > with multiple config files.  We run 6 different config files 
> > here to aid in admin with 6 different mrtg processes.  
> > By splitting the config files you could have a seperate 
> > config file for each of your 'biggies' thereby resolving any 
> > possible effect on anything else.
> > 
> > Cheers
> > 
> > Dave
> > 
> >>Have you considered splitting your configs into several smaller 
> >>ones and still use the forks option within the configs.
> >>or
> >>If it's a small group of devices that are going down every week, 
> >>you could make this group separate to the rest.
> >>
> >>HTH
> >>
> >>David Sawyer
> 
> (I should have put this in the original message) but the reason
> I don't want to run mulitple cfg files is because I use a java
> appelate called alitree which makes calls to 14all.cgi to 
> organize/display my mrtg pages.
> It's considerably more complicated to add new devices, and organize
> them in the tree if I have multiple config files, although now 
> that the concept is being suggested, I'm thinking that may be the 
> only way to go. It would also help with the speed & memory issues
> I have with 14all.cgi and big cfg files.
> 
> Take a look at http://mrtg.gvolk.com for a (small) example of
> mrtg+14all+alitree. It's really nice actually. I don't have 
> the query time cycle problem with the above site because
> it's so small. My big mrtg installation is at work, and is not 
> publicly accessible.
> 
> Thanks for the replies.
> 
> 
> 
> --
> 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
> 

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