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): 4.2.4.pre3-4 How reproducible: Always 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 before... 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-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? Thanks, 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? Thanks,
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 http://bugzilla.redhat.com/bugzilla/bug_status.cgi 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. ***