[mrtg] Re: Has anyone used a RAMdisk to speed up MRTG?

[DApel at omnipoint.com]

I've got an answer for you buried in here somewhere, but you might find all
this interesting too.  It's a long read, but I try to be as thorough as I
can.   Hope it helps.

I monitor about 900 objects with MRTG, and currently have those targets
split into 16 config files.   I'm using a Perl script (compliments of
someone on this list, but I don't remember who off-hand) that sparks up a
variable number of concurrent MRTG instances to process those 16 config
files.   Trial and error experimentation with the number of concurrent
instances showed me that 4 was the best number for the fastest completion of
all my targets.   Please note that in addition to my "normal" MRTG stuff, I
also do a bunch of other activities for each target, including grabbing some
other SNMP stats, and creating a slew of custom web pages.   Cron launches
the MRTGRUN.PL script every 5 minutes, and it takes about 2 minutes, 40
seconds on average to process all 900 objects including my extra crap.

Platform is a Pentium II 333MHz, 384MB RAM, Adaptec 2940UW controller, and
Seagate Barracuda 4GB UWSE 7200RPM disk.   Operating system is Linux
Slackware 3.6, currently running kernel 2.0.36, MRTG version 2.7.2, and Perl
5.005_02.   This machine is also my Big Brother server and a 32-port serial
Cyclades-based terminal server, so it sees a pretty fair load.

Previously, my MRTG/BB platform was an HP 9000/715 running at 75MHz, on
HP-UX 10.20, with 196MB of RAM.   I only had about 400 targets back then,
and MRTG usually took upwards of 15-20 MINUTES to run.   In case you're
curious, the 715/75 is roughly equivalent to a 486/100 in terms of specINT
and specFP. :>)

I have run a series of experiments of MRTG on Linux using both standard ext2
disk-based filesystems and ext2 ram-based filesystems.   Empirically,
execution time is only slightly faster (less than 5%) using the ramdisk.
You can probably find my test results in the archives of the
linux-config at vger.rutgers.edu mailing list, if you're curious about testing
methodology and so forth.   

I varied as many factors as I could, including keeping all the executables,
libraries, and modules chrooted in the ramdisk.  The results were kind of
staggering in that nothing seemed to make any huge difference.   The same
results occurred under kernels 2.0.36 and 2.2.2.  In some cases the ramdisk
was even slower than the hard disk, which actually makes twisted sense --
the ramdisk is a filesystem, so it will get cached as well, so you wind up
doing a lot of memory-to-memory copies that you don't need to do.   When I
tested this with only 256MB of ram in the system, I actually wound up
swapping to disk because physical memory was effectively filled with my
128MB ramdisk, the OS, plus all the caching -- obviously not the right
solution!   With the 384MB of ram, the ramdisk is slightly faster.
However, experiments with using a small ramdisk (32MB) showed no speed
increase beyond the speeds demonstrated with 384RAM/128RAMDISK, so there
seems to be a break-point somewhere.

Anyway, the end result is that even though the speed increase is negligible,
I do in fact continue to keep all my MRTG results in a ramdisk, for a couple
reasons:

1) the results are non-critical, can be lost at any time and are typically
in a state of flux.

2) disk activity is practically non-existent now, instead of being hammered
for 50% of every day.  I figure I'm saving my disk a little bit of wear and
tear.

3) I've still gots lots of memory to play with, even after the ramdisk
(128MB)and caching is accounted for.

4) I can do I/O intensive operations without impacting my mrtg runs, ie by
clogging up the disk service or wait queues.

The rc scripts just have a few extra lines to do the ramdisk at boot-up, and
to tar up the ramdisk contents to a file at shutdown.

The real bottleneck seems to be the actual code for the ramdisk itself.
The code appears to be pretty archaic in Linux time(nobody's apparently
touched it in a while), and really appears designed for standard
boot/installation purposes, not for serious high-performance filesystem
usage.   On the plus side however, it's a real treat to newfs a 256MB
ramdisk and have it complete about the same time you hit enter!   The
ramdisk.txt under the linux 2.2.2 souce Documentation directory makes
mention at the top of the page that the ramdisk code was substantially
changed at kernel release 1.3.xyz......Ancient times it seems.

The short answer is that Linux caching and buffering seems to be nearly as
efficient as a ramdisk, with a lot less hassle.   Inefficiencies appear to
exist in the MRTG process itself, but the testing I performed was done
several revs of MRTG ago, so perhaps speed improvements have manifested
themselves.  CPU speed is critical, as is having enough ram to work with.
Also, compiling perl by hand seems to result in a slightly faster execution
time -- the best execution times I had were when I statically linked ALL my
required executables by compiling from source
(awk/perl/echo/ls/bash/sh/etc/etc/etc) and ran them from a chrooted ramdisk,
so that I wasn't constantly accessing the dynamically-linked libraries from
my hard-disk.   Obviously, this is quite an undertaking and isn't something
you just rush out and do!   Even so, my performance gain was only about 8%,
which definitely wasn't worth the effort I put into it!

Doug Apel
Sr. Network Administrator
Omnipoint Technologies, Inc.
dapel at omnipoint.com



--
* To unsubscribe from the mrtg mailing list, send a message with the
  subject: unsubscribe to mrtg-request at list.ee.ethz.ch
* The mailing list archive is at http://www.ee.ethz.ch/~slist/mrtg