[mrtg] Re: How to speed up process

[Bryan Socha]

I personally have gone to splitting up mrtg into a lot of seperate cfg files
and running them all every 5 minutes..  I end up with about 40 different
copies running but its a lot easier to maintain and I don't need to worry
abou the 5 minute completion time...  I also do threshold alerting to pagers
and email so this allows for that extra time when needed.

A rough example of how they are split are:
- 1 cfg per device
- 1 cfg per service that runs over multiple devices
- 1 cfg per device for bandwidth threshold checking.

It may seem messy and can take awhile to setup but as long as you use
directories for the files, you can run a lot from 1 machine.

-----Original Message-----
From: Thomas Brian Granier [mailto:BrianG at zebec.net]
Sent: Friday, May 05, 2000 3:42 PM
To: MRTG Mailing List (E-mail)
Subject: [mrtg] How to speed up process


I've recently implemented the mrtg-ping-probe utility on my Windows NT
Workstation 4.0 (using the Windows 2000 ping.exe) and I used the 5minute
scheduler that kicks off MRTG every 5 minutes (I've found this works
better than Daemon). At any rate, once I implemented the ping-probes I
discovered that my mrtg takes longer than 5 minutes to run, which means
the second instance will halt as soon as it see the I_mrtg.cfg file. The
next step was I separated out my ping probes from my main mrtg config
file and I'm running two instances of mrtg every five minutes.. One is
the mrtg.cfg and the second is the ping.cfg. 

I've monitored this and I've seen that the mrtg.cfg can complete in
under 5 minutes unless the ping.cfg instance is running at the same time
in which case it takes about 6 minutes. I've also seen that my ping.cfg
instance takes roughly 9 minutes to complete. To alleviate the problem
I've set it up to where ping.cfg runs in the first 5 minute interval and
the next two 5 minute intervals will run the mrtg.cfg before cycling
back to the ping.cfg. I also have plans for expanding the graphs I am
making to include input/output errors, but I fear that by doing so I
might not be able to come in under the 5 minute mark. In addition to
monitoring these items I am also monitoring cumulative bandwidth by way
of adding the input and output together to come up with one graph that
will show my total bandwidth usage with respect to my CIR/EIR.

The system I am running has 128k of RAM and is running on a P III
400MhZ. I am also running What's Up Gold on this system that kicks off
every minute to test connectivity of my circuits. I've monitored the RAM
usage and I rarely see above 60 percent usage. The processor usage
reaches into the 90th percentile quite frequently and occasionally will
hit the ceiling at 100%, but I rarely see it holding there for longer
than a second or so. My suspicion is that the ping program itself is the
problem. I don't think it was designed to be a high speed program and
since I am running 49 ping probes every five minutes in addition to the
single ICMP packet that gets sent out by What's Up Gold every minute for
73 devices this can put quite a drain on resources. 

The network card that is attached to this system is a 3C905-T4 that
connects to an HP Procurve 4000. Both of these devices are capable of
100MB, yet after many attempts I can not get the card to communicate at
that speed. However, I believe this to be irrelevant because I am seeing
no more than 4 percent utilization of the network seen on the port at
the switch.

To further complicate problems This system will, in the future, be used
for remote network sniffing using Distributed Observer and Observer
probes placed in key locations in order to diagnose problems as we begin
to see them happen on remote LAN's. This package is a severe drain on
the resources of the system it runs on, so anything I can do to speed up
the performance of the MRTG would be beneficial.

The number of devices:

Items being graphed with MRTG:
Ping Probes: 49
Remote LAN I/O graphs: 49
Remote WAN graphs: 47
Local WAN graphs: 29
Local LAN graphs: 62
Total Bandwidth graphs: 47 (note this requires two snmp draws making 94
SNMP requests)

What's Up Gold monitor:
Remote devices: 47
Local devices: 26

Any advice, thoughts or comments would be greatly appreciated.

T. Brian Granier
MCSE MCP+I A+
Telecommunications Specialist
Zebec Data Systems

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

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