Bug 431439 - CRM #1765368 HOST-RESOURCES-MIB::hrProcessorLoad
CRM #1765368 HOST-RESOURCES-MIB::hrProcessorLoad
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: net-snmp (Show other bugs)
5.1
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks: 391501
  Show dependency treegraph
 
Reported: 2008-02-04 10:17 EST by Alan Matsuoka
Modified: 2010-10-22 18:13 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 17:07:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sysreport of affected system (14.43 MB, application/x-bzip2)
2008-02-04 10:26 EST, Alan Matsuoka
no flags Details
patch for RHEL5 (6.32 KB, patch)
2008-02-07 07:34 EST, Jan Safranek
no flags Details | Diff

  None (edit)
Description Alan Matsuoka 2008-02-04 10:17:33 EST
Description of problem:

RHEL 4 servers are correctly replying to the SNMP variable request
HOST-RESOURCES-MIB::hrProcessorLoad

The rpm is net-snmp-5.1.2-11.EL4.10

But for some reason RHEL 5 boxes are not displaying that variable

The rpms are

net-snmp-5.3.1-14.0.1.el5
net-snmp-libs-5.3.1-14.0.1.el5

How reproducible:
On a RHEL 5 system
# snmpwalk -c public -v 2c localhost HOST-RESOURCES-MIB::hrProcessorLoad
returns nothing.

On RHEL 4,
# snmpwalk -c public -v 2c localhost HOST-RESOURCES-MIB::hrProcessorLoad (IN RHEL4)
HOST-RESOURCES-MIB::hrProcessorLoad.768 = INTEGER: 59
Steps to Reproduce:

This issue does not seem to have been resolved by the errata provided for
bugzilla  232870. The bugzilla request was only for
HOST-RESOURCES-MIB::hrSWInstalled and the errata was to include that. This IT -
as per the customer request - is to include HOST-RESOURCES-MIB::hrProcessorLoad
which still does not work using the errata package.

How to reproduce.

Here are the modifications to /etc/snmpd/snmpd.conf used to grant access:

#       sec.name       source        community
com2sec testUser  default       public

#       groupName        securityModel   securityName
group   testGroup        v1              testUser
group   testGroup        v2c             testUser

#
view    all             included    .1      80
access  testGroup  ""          any     noauth exact   all  none  none


- Restart snmpd

Test result against RHEL4 net-snmp server.

[root@dhcp6-237 ~]# rpm -q net-snmp
net-snmp-5.1.2-11.el4_6.11.1

[root@dhcp6-237 ~]# snmpwalk -v1 -c public localhost
HOST-RESOURCES-MIB::hrProcessorLoad
HOST-RESOURCES-MIB::hrProcessorLoad.768 = INTEGER: 2

Test result against RHEL5 net-snmp-server.

[root@dhcp6-102 ~]# rpm -q net-snmp
net-snmp-5.3.1-19.el5_1.3
[root@dhcp6-102 ~]# snmpwalk -v1 -c public localhost
HOST-RESOURCES-MIB::hrProcessorLoad
[root@dhcp6-102 ~]#

Since this works fine in RHEL4, something is missing from RHEL5 and need to be
addressed.

Also found the below entry in net-snmp FAQ. /usr/share/doc/net-snmp-5.3.1/FAQ -
which says that processor statistics as a whole is available. So it seems to be
a problem with RHEL5.

What about multi-processor systems?
----------------------------------

   Sorry - the CPU statistics (both original percentages, and the
 newer raw statistics) both refer to the system as a whole.  There
 is currently no way to access individual statistics for a particular
 processor (except on Solaris systems - see below).

   Note that although the Host Resources table includes a hrProcessorTable,
 the current implementation suffers from two major flaws.  Firstly, it
 doesn't currently recognise the presence of multiple processors, and
 simply assumes that all systems have precisely one CPU.  Secondly, it
 doesn't calculate the hrProcessorLoad value correctly, and either returns
 a dummy value (based on the load average) or nothing at all.

   As of net-snmp version 5.1, the Solaris operating system delivers some
 information about multiple CPU's such as speed and type.

   Other than that, to monitor a multi-processor system, you're currently
 out of luck.  We hope to address this in a future release of the agent.
 But you've got the source, so you can always have a go yourself :-)

Actual results:

Expected results:

Additional info:
Comment 1 Alan Matsuoka 2008-02-04 10:26:46 EST
Created attachment 293894 [details]
sysreport of affected system
Comment 2 Jan Safranek 2008-02-06 10:43:30 EST
The problem is that net-snmp-5.0 (=RHEL4) shows average length of run queue
instead of proper hrProcessorLoad value (=the average, over the last minute, of
the percentage of time that this processor was not idle.) - the value you see on
RHEL4 is completely wrong.

In net-snmp-5.3 (=RHEL5) upstream decided, that it's better to report nothing
than report completely misleading value - you do not see hrProcessorLoad in the
walk.

Later on, upstream finally decided to implement it properly. The implementation
is not perfect - it periodically gathers CPU load and estimates the one-minute
average in a way, that the value is not available for first minute after snmpd
start. After the first minute, it shows correct values. I'll try to port it back
to RHEL 5.

Note to self: look at SVN commits 15026-15027, 15030, 15100 and maybe more. 
Comment 3 Jan Safranek 2008-02-07 07:34:07 EST
Created attachment 294204 [details]
patch for RHEL5

this should do the trick
Comment 6 RHEL Product and Program Management 2008-06-02 16:20:19 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 11 errata-xmlrpc 2009-01-20 17:07:10 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0230.html

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