[mrtg] Re: How to speed up process

[Matthew Moore (DSL AK)]

By default, ping probe sends out 10 ICMP packets (I think - it's in the perl
code anyway - take a look). you can change this with the -k option in
ping-probe. Eg:

Target[target]: `perl c:\mrtg\mrtg-ping-probe\mrtg-ping-probe -k 2 target`

 I currently monitor 120 devices for ping every 5 minutes, and after using
the -k 2 option, I had no problems with it taking longer than 5 minutes. I
also have 4 other cfg's monitoring the 120 devices for various snmp stats
every 5 minutes.


-----Original Message-----
From: Lars Rune Bjornevik [mailto:lrb at sysit.com]
Sent: Monday, 8 May 2000 02:56
To: MRTG Mailing List (E-mail)
Cc: 'Thomas Brian Granier'
Subject: [mrtg] Re: How to speed up process


Hi,
I don't know if I got it all, but there are two things you might do:
1 Reduse the time between pings or numer of pings (Check ping /? at the
command prompt)
2 Use 2 or more MRTG's, running simultaniusly

BTW; How did you get the W2 ping on your NT 4.0?

Hope this helps!
Lars

-----Original Message-----
From: Thomas Brian Granier [mailto:BrianG at zebec.net]
Sent: 5. mai 2000 21:42
To: MRTG Mailing List (E-mail)
Subject: 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

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