OpsMgr 2007 R2: performance tweaks

OpsMgr’s processes are constantly collecting, transferring and aggregating data. Depending on the amount of data being processed and the overall amount of config churn, this can have a reasonable performance impact.

A nice blogpost by J.C. Hornbeck described the whole OpsMgr processing model within the context of the Exchange 2010 Management Pack.

This did not only describe best practices for the management pack, but also included tweaks for OpsMgr-servers.

I made a quick summary (taken over from the blogpost) for these tweaks, and it should be considered for environments where lots of monitoring-data will be processed simultaneously.

SCOM performance tweaks

1. Patches

SCOM CU3+ is highly recommended as there are quite a few performance based fixes including setting the standard agent queue size at 100 MB instead of the old 15 MB.

2. Registry

Additionally, there are Registry Keys to update to allow the RMS to more effectively utilize the server resources and reduce additional unneeded churn. The tables below covers some of these keys:

Registry Hive
HKLM\Software\Microsoft\Microsoft Operations Manager\3.0
Key
GroupCalcPollingIntervalMilliseconds
Type
DWord
Value
000dbba0
Description
Changes the Group Calculation processing to 15 minutes.

Registry Hive
HKLM\Software\Microsoft\Microsoft Operations Manager\3.0\Config Service
Key
Polling Interval Seconds
Type
DWord
Value
00000078
Description
Changes the Config Service Polling to 2 Minutes.

Finally for the RMS, ensure that there are no agents reporting directly to the RMS whenever possible. The Exchange 2010 MP hosts a lot of “Non-Hosted” managed objects on the RMS which has to process a lot of health states as well as all alerting occurs from the RMS. Having the RMS process agent processing and dataflow should if at all possible be avoided.

On all Management Server(s):

For all Management Servers including the RMS, there are a few more registry keys to update to allow for better resource utilization for SCOM processing. The table below covers some of these keys:

Registry Hive
HKLM\System\CurrentControlSet\Services\HealthService\Parameters
Key
Persistence Cache Maximum
Type
DWord
Value
00019000
Description
Allows more memory usage for the Health Service’s Data store on the local system.

Registry Hive
HKLM\System\CurrentControlSet\Services\HealthService\Parameters Key
Persistence Version Store Maximum
Type
DWord
Value
00002800
Description
Allows more memory usage for the Health Service’s Data store on the local system.

Registry Hive
HKLM\System\CurrentControlSet\Services\HealthService\Parameters
Key
Persistence Checkpoint Depth Maximum
Type
DWord
Value
06400000
Description
Allows more memory usage for the Health Service’s Data store on the local system.

Registry Hive
HKLM\System\CurrentControlSet\Services\HealthService\Parameters Key
State Queue Items
Type
DWord
Value
00005000
Description
Allows more memory usage for the Health Service’s Data store on the local system.

Note: These updates do not apply to gateway servers.

SCOM Data warehouse: (Where applicable.)

The Exchange 2010 MP adds some new Datasets to the SCOM DW for custom reporting. These new datasets have their own set of aggregations that can take a bit more time to complete than normal. Thus, you need to increase the timeout for DW processing to allow these aggregations to finish.

Registry Hive
HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Data Warehouse

Key
Command Timeout Seconds
Type
DWord
Value
00000384
Description
Updates the DW processing timeout from 5 minutes to 15 minutes.

Note: This needs to be done on every Management Server (including the RMS).

Note: This may require to be up to 30 minutes for the timeout depending on how much data flow there is. (Mainly event and performance collection.)

Advertisements
This entry was posted in Uncategorized and tagged . Bookmark the permalink.

3 Responses to OpsMgr 2007 R2: performance tweaks

  1. Rasmus says:

    Thank you for the info, this is really good

    “Checkpoint Depth Maximum” should be “Persistence Checkpoint Depth Maximum” is that right?

  2. janvm says:

    Rasmus,

    Thank you for pointing out the error, it has been fixed!

  3. John says:

    Is the dword in hexadecimal or decimal? Thanks!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s