Why is check_openmanage so slow on PowerEdge R510?
Trond Hasle Amundsen
t.h.amundsen at usit.uio.no
Wed Apr 13 17:39:54 CEST 2011
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
More information about the Users
mailing list