MSMQ 4.0 Performance Counters and the NetNameForPerfCounters Registry Key
MSMQ provides several sets of performance counters which query the state of the service and other objects (sessions, queues, etc.) and can be used in various monitoring systems. There are a few KB articles and blog entries explaining things you need to know when using the performance counters. This document explains what is new in MSMQ 4.0 performance counters and what you need to know when using the performance counters in cluster setup.
Before MSMQ 4.0 (Vista and Windows Server 2008), MSMQ performance counters were implemented based on PerfLib v1. In this model, a shared memory is created for data exchange between the MSMQ service and the Messaging Queuing Performance Monitoring DLL (mqperf.dll). The shared memory is named by the name of the computer under whose context MSMQ is running. Because PerfLib v1 is not cluster aware, remote query of the virtual server performance counters may not work as expected (https://support.microsoft.com/kb/267316). To solve this issue, a registry key NetNameForPerfCounters was introduced.
In MSMQ 4.0, MSMQ performance counter implementation is based on PerfLib v2, which doesn’t require a shared memory and a performance monitoring DLL. This migration enables local and remote query of performance counters by just specifying the server name; it is expected to work without using the registry key. However, two cluster-related issues were found during the RC testing period:
1. If two or more service instances are running on one node at the same time, performance counter query does not work for either of them.
2. Remote query of clustered MSMQ service counters from a down-level OS does not work as expected.
A decision was made to add back the registry key to partially solve the first issue. Because of the change in PerfLib v2, this registry key doesn’t retain the same behavior as before. The behavior difference is explained under different scenarios. In all scenarios, the performances counters are for services that are running. Some of the terminologies used in the explanation are listed below:
1. Service – the MSMQ service
2. Non-clustered computer – computer that doesn’t have cluster service installed.
3. Clustered node - computer that hosts a cluster.
4. Consumer – applications that call PerfLib APIs to query performance counters.
5. Local – the consumer is running on the same physical machine as the provider (can be under different virtual server context).
6. Remote – the consumer is running on a different physical machine than the provider.
7. Down-level OS – Windows 2000, XP, 2003
8. Virtual server – the Network Name resource an MSMQ resource belongs to.
Scenario 1: non-clustered computer, service is running.
In this scenario, the registry key is not needed. The performance counters are available for both local and remote (including down-level OS) consumers.
Scenario 2: clustered node, node’s service is running and all clustered MSMQ resources are offline.
Assume the node name is XYZ and the query is for XYZ. If the registry key is not set or set to XYZ, the behavior is the same as in scenario 1. Otherwise, no performance counters of any service are available to any consumer. In this scenario, WS08 has the same behavior as WS03.
Table 1: XYZ Counters - Only Node’s Service Running on WS08/WS03 Cluster
Consumer Key |
Local |
Remote, Vista/WS08 |
Remote, Down-level |
Not set |
Working |
Working |
Working |
Set to XYZ |
Working |
Working |
Working |
Set to non-XYZ |
Not working |
Not working |
Not working |
Scenario 3: clustered node, node’s service is stopped and one clustered MSMQ resource is online (the corresponding service is running).
In the following discussion, counters are assumed for the running clustered service and the name of the corresponding virtual server is XYZ.
If the registry key is not set or set to XYZ, local query and remote query from Vista/WS08 machines are working. Local consumer doesn’t have to be running under the virtual server context. This is an improvement in MSMQ 4.0. Remote query from down-level OS is not working. If the registry key is set but not XYZ, no counters are available to any consumer. The following tables list the results for WS08 and WS03 with differences highlighted.
Table 2.1: XYZ Counters - One Virtual Server Running on WS08 Cluster
Consumer Key |
Local |
Remote, Vista/WS08 |
Remote, Down-level |
Not set |
Working |
Working |
Not working |
Set to XYZ |
Working |
Working |
Not working |
Set to non-XYZ |
Not working |
Not working |
Not working |
Table 2.2: XYZ Counters - One Virtual Server Running on WS03 Cluster
Consumer Key |
Local |
Remote, Vista/WS08 |
Remote, Down-level |
Not set |
Working only when under XYZ context |
Not working |
Not working |
Set to XYZ |
Working |
Working |
Working |
Set to non-XYZ |
Not working |
Not working |
Not working |
Scenario 4: clustered node, two or more services are running.
The services running can belong to the node or to virtual servers. Assume the counter that the consumer wants to query is for computer/virtual server XYZ.
If the registry key is not set, performance counter query for any running service is not working for any consumer. This is a regression from Windows 2003, where counter query is working when consumer is running under the same computer context as the service. If the registry key is set to XYZ, the result depends on whether XYZ is the node or a virtual server. If XYZ is a node, the result is the same as in scenario 2. If XYZ is a virtual server, local query and remote query form Vista/WS08 machines are working, but remote query from down-level OS is not working. This is another regression from Windows 2003. If the registry key is set but not XYZ, no counters for XYZ are available for any consumer.
Table 3.1: XYZ Counters - Two or More Services Running on WS08 Cluster
Consumer Key |
Local |
Remote, Vista/WS08 |
Remote, Down-level |
Not set |
Not working |
Not working |
Not working |
Set to XYZ |
Working |
Working |
Working only when XYZ is the node |
Set to non-XYZ |
Not working |
Not working |
Not working |
Table 3.2: XYZ Counters - Two or More Services Running on WS03 Cluster
Consumer Key |
Local |
Remote, Vista/WS08 |
Remote, Down-level |
Not set |
Working only when under XYZ context |
Working only when XYZ is the node |
Working only when XYZ is the node |
Set to XYZ |
Working |
Working |
Working |
Set to non-XYZ |
Not working |
Not working |
Not working |
Summary
The results can be summarized as:
1. MSMQ 4.0 performance counters improved for single service scenario. If the consumer is running on a Vista/WS08 machine, no key is needed and the counter query is working even for clustered service.
2. There are some regressions in multiple services scenario. No counters of any service are available when the key is not set. Setting the key will bring MSMQ 4.0 on parity with MSMQ 3.0 if the consumer is running on Vista/WS08 machine.
3. Performance counters of a clustered MSMQ service are not available to any down-level consumers, regardless setting the key or not. This may become a serious issue for customer, and we are actively seeking solutions to it.
Another difference worth mentioning is that, on WS03 cluster, changing the registry key will change the performance counter provider without restarting all services, provided all consumers are shutdown beforehand. However, on WS08 cluster, all services have to be restarted for the registry key to take effect.
On WS03 cluster, the value of the NetNameForPerCounters registry key needs to be in capital letters. This is not required on WS08 cluster.
—Xin Chen
MSMQ Development Team
Comments
- Anonymous
June 19, 2009
PingBack from http://mydebtconsolidator.info/story.php?id=15702