OpenManage Server Administrator

I am also experiencing high utilization (for both processor and "other" I/O) from the DSM SA Data Manager service on a recurring basis. The high-level server configuration: 

-  Dell PowerEdge 2950 dual-socket dual-core (4 cores total) – 2 x Intel Xeon 5160 3.0 Ghz

-  8 GB RAM

-  1 PERC-5i and 2 PERC-5e RAID controllers

-  2 x 73 GB SAS disks (for OS – configured as a single RAID-1 virtual disk)

-  46 x 146 GB 15KRPM SAS disks (configured as 4 virtual disks: 4-disk RAID-5, 8-disk RAID-5, 15-disk RAID-5, 19-disk RAID-5)

-  Microsoft Windows Server 2003 Enterprise Edition SP1 (x86 32-bit)

-  Microsoft SQL Server 2005 Enterprise Edition SP2 (x86 32-bit)

-  Dell OpenManage Server Administrator 5.3.0 

I ran a PerfMon trace on the service and other resources (1 second sampling interval) and observed the following patterns with no other workloads running on the server: 

-  Processor spikes about every 60 seconds of 25% (up to 100% of a single processor core on the 4-core server), lasting for 8-10 seconds.  The 60 second pattern appears to be 60 seconds from the end of one spike to the start of the next spike, rather than from start of one spike to start of next spike.  The spike is all from the DSM SA Data Manager service, and not from other workloads on the server.  If you average out this usage over time, these processor spikes appear to be consuming 8-15% of a single core (or 2-4% of all 4 cores).  In my opinion, this is excessive resource consumption for operational management software. 

-  During the processor spike, there is also a spike of "other" I/O requests in the range of 250,000 - 350,000 read "other" I/Os per seconds (this is not a typo!) with no write “other” I/O requests - again, all from the DSM SA Data Manager service.  Using Sysinternals Process Explorer to observe the DSM SA Data Manager service process, total "other" I/Os for this service easily get into the billions after only a few days of uptime (which is how I first came to notice this excessive behavior). 

-  Monitored all other logical disk drives on the server - no other I/Os (read / write) going on during the spikes. -  In addition to the large spikes in processor and “other” I/O described above, there are also other smaller periodic usage patterns: 3-5% processor for the same service lasting 1-2 seconds every 20-30 seconds and 10,000-15,000 “other” write I/Os per second with no read “other” I/Os per second. 

-  The computed average “other” I/O transfer size (take “other” bytes transferred per collected interval and divide by “other” I/Os in same interval) comes to 44 bytes per I/O in all cases.  My guess is that these are some type of control I/Os to get or confirm configuration info.  This same 44 bytes per I/O applies to both the very large I/O counts from the every 60 second spikes as well as the smaller (but still large) I/O counts that occur during the 20-30 second smaller “blips”.

I was conducting some benchmarks on this server prior to discovering this behavior.  The benchmark results were not consistent from run to run, and I did not have a good explanation for the variations.  When I discovered this behavior from the DSM SA Data Manager service, I explored what this service was needed for, and whether is could be stopped during benchmark runs to eliminate the effects from the benchmarks results.  I found that the service is one of 4 services that are part of Dell OpenManage Server Administrator (OMSA).  The services are used by the OMSA console that allows aspects of server configuration to be viewed or changed (such as disk storage – virtual disks, RAID level, etc.).  The OMREPORT tool that can query server configuration details also uses these services.  The services can be safely stopped to run the benchmarks, and restarted if needed afterwards.  While the services are stopped, the OMSA console and OMREPORT command can’t be used.

I have observed similar behavior of this service on at least two other servers:

-  Same server model and processors, 16 GB, similar disk configuration, running OMSA 5.2.0

-  Same server model and processors, 4 GB, less disk, running OMSA 5.4.0

The questions I have include:

1.  One reply to this thread said that the service “spikes when checking the Embedded Server Management for current status”.  100% of a processor core and 2.5 million “other” I/Os in an 8-10 second period every 60-70 seconds is not a trivial action.  I am curious what “status information” is being gathered that requires this level of intensity and frequency.

2.  Is this behavior considered normal, or is it possibly improper behavior caused by a defect in OMSA?

3.  Is the polling frequency of the recurring events (both the large spikes and small “blips”) configurable to a less frequent interval (through a GUI or a configuration file change)?  There are ini files under various sub-folders under the C:\Program Files\Dell\SysMgt folder, but I don’t know enough abut the content to make changes without possible adverse effects on other aspects of these services.  What are the impacts of a less frequent polling interval on these services?

I hope to better understand this behavior, and trust that Dell will initiate corrective changes if the behavior is not warranted.

I look forward to your reply.

Scott R.

Thank you for your very thorough assessment of the problem.  Please update to OMSA 5.4, and see if the problem persists, I think the developers are aware of it and may have addressed it in that release:

http://support.dell.com/support/downloads/download.aspx?&fileid=251117

If the problems persist, what versions are on your system BIOS, ESM, PERC driver and PERC firmware?  If any of these are not at the latest versions, they may cause communication problems with OMSA.  Please reply here so I can find out what fixes the problem.