Red Hat Bugzilla – Bug 63770
Huge performance drop with ucd-snmp-4.2.4.pre3-4 over 4.2.3
Last modified: 2007-04-18 12:42:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Description of problem:
The snmp utilities with 4.2.4 require an order of magnitude more time and CPU
to work than the 4.2.3 utilities do (approximately five times as much)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run "time snmptranslate -Of -IR sysContact" with 4.2.3 installed
2. Upgrade to 4.2.4.pre3-4 (via Rawhide RPMs) and ensure the agent was restarted
3. Run "time snmptranslate -Of -IR sysContact" with 4.2.4 installed
Actual Results: The second query requires 2.5 seconds to run. The first
requires 0.5 seconds (note again, the 5x increase).
Expected Results: The two queries should have taken roughly the same amount of
time to complete.
The machine that we tested this on ran at about 5% utilized, doing its regular
queries of other machines (snmpgets). Immediately after installing, the
utilization went to 25%. A good thing that we were not heavily using it
During troubleshooting, the utilization decreased linearly as we removed the
number of hosts it was polling.
Normally we'd just use 4.2.3, but diskspace support is broken in the Redhat RPM
of that version. If a repaired RPM were released for that version, we'd
happily use it.
A tarball compile from UCD-SNMP's (net-snmp's) site is working perfectly.
One would conclude that there is something in the Redhat RPMs that's causing
this to happen.
We're also easily reproduced this problem on our other (faster) test machines.
Our policy is to not do tarball compiles on our production machines, though, so
we're eagerly awaiting another Rawhide version with this fixed. =)
If you could pinpoint the problem i'd be much more likely to be able to help.
Did you try to configure the tarball version with the same configure flags we
use? Did you check if any of the patches could cause this problem?
Read ya, Phil
I used the default configuration options for both the tarball and for the RPM
(i.e. I did a ./configure ; make ; make install on the tarball). I don't know
if the options are the same; I am not a C developer.
Please respond if this is not enough information to duplicate the problem
(although I should think it is). We've duplicated the problem on every machine
we have tried it on, though.
Well, we're using several additional options for almost all packages in order to
enable new features or similar things.
So if your tarball version has not been built with the same options some
features might have been left out, resulting in possibly less information being
collected and therefore being much faster.
Could you try it with this configure line:
./configure i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
--sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
--includedir=/usr/include/ucd-snmp --libdir=/usr/lib --libexecdir=/usr/libexec
--localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man
--infodir=/usr/share/info --enable-static --enable-shared '--with-cflags=-O2
-march=i386 -mcpu=i686' --with-sys-location=Unknown
'--with-mib-modules=host agentx smux' --enable-reentrant --with-libwrap=/usr/lib
--sysconfdir=/etc --enable-ipv6 --with-sys-contact=root@localhost
and see if the performance is still much slower?
Read ya, Phil
OK, done. The compiled snmpget binary runs "normally" as well (i.e. the
desired 4.2.3 speed).
I noticed the snmpget file installed via the 4.2.4.pre3-4 RPM is about twice as
large (!) as either of the ones in the build directories (there is one for the
default conf and one for the conf you provided). I am not sure if something
funky gets done to them when they are installed- if not, this might be a good
thing for you to take a look at. =)
Wes Hardaker has volunteered to write a 4.2.4 Redhat RPM for ucd-snmp's
download page in order to address this problem, however, he is not sure if
these is a licence agreement for the .spec file. Do you know if the .spec file
in the RH RPM can be used, or will he have to write a fresh one?
To be honest, it also might be either related to one of our required patches
and/or the configuration we use.
I'll see if i can reproduce it myself and nail it down.
Read ya, Phil
Despite this bug, this version was committed to Red Hat 7.3!?!
Please, address this problem as soon as possible, before too many other people
start using it.
Anyone still looking at this?? I have some more information.
This bug persists with the latest Red Hat 4.2.5 Errata release. Additionally,
this bug is ALSO present with ucd-snmp's 4.2.5 version (compiled using RPM and
no Red Hat patches). Perhaps there is something in 4.2.5 that was included
with Red Hat's 4.2.4 and 4.2.5 versions that is causing this problem?
> Anyone still looking at this??
This bug has been inappropriately marked MODIFIED. Please review the bug life
cycle information at
Marking a bug MODIFIED is a really good way to get developers to ignore it,
since MODIFIED is taken to mean "fixed pending verification".
Changing bug status to ASSIGNED.
*** Bug 73709 has been marked as a duplicate of this bug. ***