Why is check_openmanage so slow on PowerEdge R510?

[Trond Hasle Amundsen]

Helmut Wollmersdorfer <helmut.wollmersdorfer at fixpunkt.de> writes:

> new to this architecture I installed the monitoring plugin check- 
> openmanage and was surprised about the performance:
>
> root at xen10:~# time perl /usr/lib/nagios/plugins/check_openmanage  -d |  
> head -n 3
> sh: /bin/rpm: not found
>     System:      		PowerEdge R510 II        	OMSA version:    6.5.0
>     ServiceTag:  	1Z7215J                  		Plugin version:  3.6.5
>     BIOS/date:   	1.6.3 02/01/2011        	 	Checking mode:   local
>
> real		0m3.426s
> user	0m2.456s
> sys		0m0.544s
>
> OS: Debian
> root at xen10:~# uname -a
> Linux xen10 2.6.32-5-xen-amd64 #1 SMP Tue Mar 8 00:01:30 UTC 2011  
> x86_64 GNU/Linux
>
> Most calls of check_openmanage (from the shell) take 3 - 4 seconds,  
> some with '--only' are faster, but not as fast as omreport:
>
> root at xen10:~# time perl /usr/lib/nagios/plugins/check_openmanage  -- 
> only fans
> FANS OK - 5 fan probes checked
>
> real	0m0.716s
>
>
> root at xen10:~# time /opt/dell/srvadmin/bin/omreport chassis fans
> Fan Probes Information
>
> Fan Redundancy
> Redundancy Status : Full
> [...]
>
> real	0m0.037s
>
> In comparison called with the option --help (does nearly nothing) the  
> execution time is as expected for loading the perl interpreter and  
> compiling the source:
>
> root at xen10:~# time perl /usr/lib/nagios/plugins/check_openmanage  -h
> [...]
> real	0m0.064s
>
> What can be the reason?

Hi Helmut,

The simple answer is that omreport commands take time. They represent
the vast majority of the plugin execution time.

The reason that 'check_openmanage --only fans' takes significantly more
time than the corresponding omreport command is that the plugin first
runs 'omreport -?' to determine if this is a blade or not. If you add
the time it takes to run 'omreport -?', the omreport fans command and
perl interpreter time you should arrive at about the time it takes
'check_openmanage --only fans' to finish.

Note that storage takes time to check, since the omreport commands for
storage are slow. This is especially true if you have a lot of storage
(e.g. an R510).

Also note that if you use the '-d' option, check_openmanage will run
'omreport about' to determine the OMSA version. This is a slow command
and adds to the overall execution time.

The plugin is much faster if used in SNMP mode, especially if you lots
of storage. Example from a 2950 with a couple of MD1000 shelves of extra
storage:

  $ time ./check_openmanage -H foo
  OK - System: 'PowerEdge 2950 III', SN: 'XXXXXXX', 16 GB ram (8 dimms), 3
  logical drives, 32 physical drives
  
  real    0m1.725s
  user    0m0.397s
  sys     0m0.013s
  
  foo /# time /usr/lib64/nagios/plugins/check_openmanage 
  OK - System: 'PowerEdge 2950 III', SN: 'XXXXXXX, 16 GB ram (8 dimms), 3
  logical drives, 32 physical drives
  
  real    0m4.188s
  user    0m2.997s
  sys     0m0.821s

As you can see the footprint is significantly smaller with SNMP, so if
this is a concern then SNMP should be your weapon of choice :)

Cheers,
-- 
Trond H. Amundsen <t.h.amundsen at usit.uio.no>
Center for Information Technology Services, University of Oslo

------------------------------------------------------------------------------
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null