Exchange 2013 – Performance counters and their thresholds


 

perfmon_0000.icoHi all,

 

the official TechNet most important performance counters list to monitor for Exchange 2013 is now available !

 

The good news is that since Exchange 2013 is now a single box (-ish as separable CAS role is merely just a protocol forwarder), the counters to monitor are now simplified down to 71 counters:

 

Counter category

With Threshold

Without Threshold
(Load Indicator)

Client Access Server Counters

 

12

Database Counters

5

4

HTTP Proxy Counters

 

7

RPC Client Access Counters

2

4

ASP.NET

4

2

Processor and Process Counters

4

1

Netlogon Counters

 

5

Information Store Counters

3

2

Exchange Domain Controller Connectivity Counters

4

 

Network counters

3

1

Workload Management Counters

 

3

.NET Framework Counters

2

1

Memory counters

2

 

Grand Total

29

42

 

Remember the process to analyze an Exchange performance concern (once it’s determined that the latency is server-side and not client side or network related):

1. Check the RPC requests as well as the RPC latency counters

and then:

2. Determine which is likely the cause by checking

2.1- the Database counters to see if some databases have read or write latency => then check the underlying disk latency counters to see if something with the disk subsystem is wrong (can be the queue depth, or simply not enough I/Os that a LUN can provide)

           2.1.1 - Disk counters to monitor to rule out performance issues caused by the disk subsystem are:

  • Logical Disk \ Avg Disk Sec/Read (this one is important for end-user performance consequences –> usually bad performance on this counter is spikes over 50ms and are reflected on the RPC Average Latency from MSExchangeIS, and then on RPC Average Latency from MSExchange RPCClientAccess counters, and eventually on the Outlook end-user performance)
  • Logical Disk \ Avg Disk Sec /Write (this one is important as well as it will slow down the data flush from memory to the EDB database on disk, having a consequence of filling the database cache in memory, then you’ll get database transaction stalls, then transaction will have to wait until they can be put in the memory aka database cache, resulting in the very end in RPC Average Latency as well – but you’ll see some issues on Database transaction stalls first, or Log Records stalls if the Write Disk performance is bad on Log drives)
  • Logical Disk \ Transactions per second– this one reflects the IOPS that the Exchange server is demanding to the disk subsystem – sizing tells you how much IOPS Exchange may ask at peak load.
  • NOTE: disk related performance issues can be related not only to a lack of disks in a LUN or by a hardware issue, but also by a configuration issue (like the queue depth on the server's HBA card, or the queue depth configuration on the SAN switch, or by outdated HBA drivers on the server, etc...

 

              2.1.2 - Check my older Blog Post on the MSPFE TechNet Blog for complete performance assessment methodology, it remains the same general method for all Exchange versions:

Click HERE to go to my detailed Exchange Performance Assessment Methodology for all Exchange versions...

  •   
  • 2.2. the CPU and Memorycounters to see if there are too much pressure on these two basic counters
  • 2.3. The RPC Operations/sec, active user count and active connection count counters to see if there is an unusual load that’s putting the server’s resources down (usually CPU and Memory suffer first if it’s the case – Database latency and disk also can be the cause if the sizing hasn’t been done properly)
  • 2.4. if none of the above 2.x counters shows unusual values, also check your Antivirus counters, which can also block the RPC processing sometimes (seen on a customer’s site: RPC requests growing and hardly decreasing, RPC latency quite high, but all other counters like CPU, Database latency, etc… were below the error thresholds…)  

 

Check out all the counters and their description below:

Exchange 2013 Performance Counters

https://technet.microsoft.com/en-us/library/dn904093(v=exchg.150).aspx

 

For a summarized view, below is a sub-list of the above Technet Exchange counters to show only those which have thresholds (29 counters have thresholds out of the 71 TechNet counters) – the TechNet article above has the entire list and descriptions. You’ll see below a picture with colors for readability between categories (click on the small image to open the original one in a new window), the other table is a simple table to enable you to copy paste these to make it a bit easier to integrate the counters in SCOM or Perfmon custom alerts for example…

E2013 Perf Counters Thresholds

 

 

 

Type Counter full path
(all instances)
AVG MIN MAX
Exchange Domain Controller Connectivity Counters MSExchange ADAccess Domain Controllers(*)\LDAP Read Time <= 50ms   <= 100ms
Exchange Domain Controller Connectivity Counters MSExchange ADAccess Domain Controllers(*)\LDAP Search Time <= 50ms   <= 100ms
Exchange Domain Controller Connectivity Counters MSExchange ADAccess Processes(*)\LDAP Read Time <= 50ms   <= 100ms
Exchange Domain Controller Connectivity Counters MSExchange ADAccess Processes(*)\LDAP Search Time <= 50ms   <= 100ms
Processor and Process Counters Processor(_Total)\% Processor Time <= 75%    
Processor and Process Counters Processor(_Total)\% User Time <= 75%    
Processor and Process Counters Processor(_Total)\% Privileged Time <= 75%    
Processor and Process Counters System\Processor Queue Length (all instances)     <= 5 x Nb procs
Memory counters Memory\Available Mbytes   >= 5% total RAM  
Memory counters Memory\% Committed Bytes In Use     <= 80%
.NET Framework Counters .NET CLR Memory(*)\% Time in GC <= 10%    
.NET Framework Counters .NET CLR Exceptions(*)\# of Excepts Thrown / sec <= Web Service(_Total)\Connection attempts/sec x 0.5    
Network counters Network Interface(*)\Packets Outbound Errors     = 0
Network counters TCPv4\Connections Reset should never increase should never increase should never increase
Network counters TCPv6\Connections Reset should never increase should never increase should never increase
Database Counters MSExchange Database ==> Instances(*)\I/O Database Reads (Attached) Average Latency <= 20ms    
Database Counters MSExchange Database ==> Instances(*)\I/O Database Writes (Attached) Average Latency <= 50ms    
Database Counters MSExchange Database ==> Instances(*)\I/O Log Writes Average Latency <= 10ms    
Database Counters MSExchange Database ==> Instances(*)\I/O Database Reads (Recovery) Average Latency <= 200ms    
Database Counters MSExchange Database ==> Instances(*)\I/O Database Writes (Recovery) Average Latency <= 200ms    
ASP.NET ASP.NET\Application Restarts     = 0
ASP.NET ASP.NET\Worker Process Restarts     = 0
ASP.NET ASP.NET\Request Wait Time     = 0
ASP.NET ASP.NET Applications(*)\Requests In Application Queue     = 0
RPC Client Access Counters MSExchange RpcClientAccess\RPC Averaged Latency     <= 250ms
RPC Client Access Counters MSExchange RpcClientAccess\RPC Requests     <= 40
Information Store Counters MSExchangeIS Client Type\RPC Requests     <= 70
Information Store Counters MSExchangeIS Client Type(*)\RPC Average Latency <= 50ms    
Information Store Counters MSExchangeIS Store(*)\RPC Average Latency <= 50ms   <= 100ms
Comments (6)

  1. Morel says:

    Thanks !

  2. Andy says:

    Sammy,
    i am pretty sure that the value for "MSExchange RpcClientAccessRPC Averaged Latency" should be below 50 or 30 ms. Otherwise things will get slow for the client. Could you double check the 250 ms specified?
    The counter does not show the cause of the problem but it seems to be perfect to indicate if end users will call you soon. So it is important.

  3. SammyKrosoft says:

    Hi Andy,

    the TechNet site indicates 250ms for the RpcClientAccessRPC average latency counter, I agree that's way beyond the threshold we have for MSExchangeIS RPC Average Latency on previous Exchange versions - however, we still have this 50ms threshold limit in
    Exchange 2013 for the MSExchangeIS Client Type(*)RPC Average Latency counter => do you see high spikes above 50ms for instances of this counter as well ?

    Second thing, if both the MSExchangeIS Client Type(*) RPC average latency and RPCClientAccess RPC average latency counters show values lower than our TechNet thresholds, you will have to see the Outlook "Connection Status" as well, especially the values
    on Avg Resp. and Avg Proc. columns : Avg. Proc. indicates the Server Side processing latency. If it's lower than 30ms / 50ms, then there are good chances that we're fine server side - my friend Neil Johnson uses a 25ms threshold recommendation for Avg Proc.,
    which helps staying on the safe side. Then look at the Avg. Resp. values, if these are greater than 325ms/350ms, that's not good even when you're on Outlook Cached mode, and then the latency is more on the network side.

    IMPORTANT: Outlook ONLINE Mode requires a latency lower than 110ms, which would correspond to an "Avg. Resp." time lower than 135ms or 150ms.

    See Neil's blog post about these values - this is for Office 365 but applies to help determining if the latency issue is Server related or network related as well:
    http://blogs.technet.com/b/neiljohn/archive/2012/01/23/outlook-performance-troubleshooting-including-office-365.aspx

    Also, if you determined that the issue is on the client side, especially on cached mode, consider Antivirus exclusions and check if an Add-In is not slowing Outlook down:
    > Troubleshooting Outlook 2010 performance issues
    https://support.microsoft.com/en-us/kb/2695805

    > Antivirus Exclusions on Outlook
    http://blogs.technet.com/b/samdrey/archive/2014/06/20/outlook-antivirus-exclusions-reminder.aspx

    Note finally that storing PSTs on network drives creates lots of unexpected issues on Outlook (recently I had messages staying in the "Outbox", never leaving, and eventually lost after Outlook restarts - or earlier I had rules that transferred messages into
    a PST that were broken after a File Server outage, not counting the several Outlook freezes caused by these, and sometimes we had PST corruptions as well ...)

    Hope that helps,
    Sam.

  4. IT-Tankers says:

    Hey - I'm pretty sure that >> Information Store Counters MSExchangeIS Client Type\RPC Requests >> Is not a threshold type counter so value <= 70 cannot by used. This is a cumulative type counter.

    1. SammyKrosoft says:

      humm I have to triple check this ... if it's so, we'll have to correct our original TechNet article then ... thanks for the heads-up !

Skip to main content