[mrtg] Re: bad performance: MRTG 2.9.4 / RRDs / rrdtool 1.0.28

Bjorn Nordbo bn at nextra.com
Tue Jan 9 18:48:03 MET 2001

Rainer Bawidamann wrote:
> In article <20010109001401.A3354 at nextra.com>,
> 	bn at nextra.com (Bjorn Nordbo) writes:
> > 
> > I have a Sun box with 4 450MHz Ultra IIi's, 2GB RAM which I use for
> > collection information through SNMP. The RRD-archives rests on a
> > NetApp for performance reasons. But still I get into trouble when
> > the config files reaches 500 targets. The collect operation is done
> > in about 30 seconds with 8 forks, but the RRDs::update()'s takes a
> > very long time to complete, about one second each (I have confirmed
> > that MRTG does one RRDs::update() per target).
> NetApp - is this a NFS server? NFS is very slow compared to a local
> disc. I know of installations with 4400+ targets where RRDs::update is
> not a problem.

Yes, the irony is that we installed the NFS server to boost the
performance of MRTG/rateup, as NetApp's has write caching. It
seems, however, that it's simply the bandwidth to the NFS box
which is the problem (the traffic is trunked to a router for
access list processing and back to another VLAN). I will try to
add another interface to the NetApp an attach it to the same
VLAN as the MRTG collector and see if that helps.

On local disk I managed 557 targets in 28 seconds, so the problem
is definately with NFS -- hopefully only a bandwidth (or router
CPU) problem and not a protocol problem.

> >       527 188.4178 2.980000   410:        RRDs::update("$rrd",
> >      2640 50.81802 0.090000  1581:      my $line = <$h>; # must be a simple
> >       527 21.86756 0.550000   417:        my $lasttime = RRDs::last($rrd);
> >       527 15.09493 0.300000   402:            RRDs::tune(@args);
> >       527 2.734013 0.700000   421:        my @fetch =
> Here you will see 4 calls to RRDs: tune (called earlier than in this
> listing), update, last, fetch (fetch not listed). The last and fetch
> calls could be optimized away if you don't use threshold checking, the
> tune call could be skipped with two 'stat' calls before most of the
> time. But as you're the first that complains about rrdtool performance
> (did you ever use rateup?) I think the problem is NFS.

Ah, of course. I'm sorry -- I must have been really tired yesterday.

Thanks for your very good explaination, and you seems to be right
about the reason for this problem. I'm not sure about how the switch
matrices of the 7206VXR works, but worst case is that it passes
every NFS packet to the main CPU for routing. In that case -- well,
then I'm amazed that it manages as much as one update/second. :-)

Thanks to you and Tobi for helping me out on this one!

Bjørn Nordbø  -  IP Development  -  Nextra Norway

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