Bug 63770 - Huge performance drop with ucd-snmp-4.2.4.pre3-4 over 4.2.3
Huge performance drop with ucd-snmp-4.2.4.pre3-4 over 4.2.3
Product: Red Hat Linux
Classification: Retired
Component: ucd-snmp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Radek Vokal
Brock Organ
: 73709 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2002-04-18 12:46 EDT by Darren Gamble
Modified: 2007-04-18 12:42 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-01-18 07:37:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Darren Gamble 2002-04-18 12:46:04 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):

How reproducible:

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.

Additional info:

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.
Comment 1 Darren Gamble 2002-04-19 15:53:29 EDT
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. =)
Comment 2 Phil Knirsch 2002-04-22 05:55:18 EDT
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
Comment 3 Darren Gamble 2002-04-22 10:16:53 EDT
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.
Comment 4 Phil Knirsch 2002-04-22 10:22:45 EDT
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-logfile=/var/log/snmpd.log --with-persistent-directory=/var/ucd-snmp
'--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
Comment 5 Darren Gamble 2002-04-22 12:53:06 EDT
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. =)
Comment 6 Darren Gamble 2002-04-24 11:59:13 EDT
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?

Comment 7 Phil Knirsch 2002-04-25 07:12:12 EDT
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
Comment 8 Darren Gamble 2002-05-15 13:57:28 EDT
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.
Comment 9 Darren Gamble 2002-07-10 22:29:25 EDT
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?
Comment 10 Mike McLean 2003-01-02 14:53:22 EST
> 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.
Comment 11 Phil Knirsch 2003-03-28 08:03:53 EST
*** Bug 73709 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.