The common counters, in next session the WEB and ASP.NET counters and Database counters too.
| Category | Counter | Description | Recommendations |
| Processor | % Processor Time | Total percentage of processor utilization across all processes | General indication of system utilization |
| Process | % Processor Time | Like before but specific to a single process. | Isolate the problems of the System from the others like Data, etc |
| Process | Working Set | The amount of memory pages in use by all threads within the process, is listed in bytes. | Memory usage of a specific process. |
| Memory | Available Mbytes | The amount of available physical memory in the system. | Can show if an application has a memory leak |
| Memory | Pages/Sec | The number of hard faults per second. A hard fault is when pages of memory are read from, or written to, disk. | Since disk operations are relatively slow compared to memory operations, hard faults are quite expensive in terms of system performance. The larger this counter, the worse the overall system
performance will be. This counter should ideally be zero or at least very low. |
| Memory | Page Faults/Sec | Very related to the previous.
Represents the number of hard and soft faults per second when soft fault is where a page of memory was elsewhere in physical memory, and needed to be swapped into the process address space. | Since memory operations are very fast, having a high number of soft faults is generally OK, as most systems can cope with this. Monitoring this counter can help provide the tipping point where hard faults begin to occur and where soft faults become excessive. |
| .NET CLR Memory | Gen 0 heap size, Gen 1 heap size, Gen 2 heap size | Part of the .NET CLR garbage collector mechanism collection.
The Gen 0 heap size, Gen 1 heap size, and Gen 2 heap size represent the memory heap size of each respective generation. | Heap size counters should show approximately a 1:10:100 pattern |
| .NET CLR Memory | #Gen 0 Collections, #Gen 1 Collections, #Gen 2 Collections | Part of the .NET CLR garbage collector mechanism collection.
Generation 0 (Gen0): The shortest lived, most often collected and least expensive to collect.
Generation 2: Contains the longest-living objects, is collected the least often, and is the most expensive in terms of performance to collect.
The #Gen 0, #Gen 1, and #Gen 2 collection counters represent the number of times each generation had a garbage collection performed. | #Gen 0, #Gen 1, and #Gen 2 collections should follow a 100:10:1 pattern |
| .NET CLR Exceptions | # of Excepts Thrown / sec | The number of exceptions being thrown per second by the
application, and should be very low. | If a web application utilizes a lot of Response.Redirect calls then will generate a thread aborted exception.
If this counter is high and there are a lot of Response.Redirect calls in the web application, then the counter may be representative of this, and it may be worthwhile trying to replace the calls with ones to the overload of Response.Redirect, which also takes a bool as the second parameter, and set that bool to false. This causes the request to not immediately terminate processing of the current page, (which is what causes the thread aborted exception |
| .NET CLR JIT | % Time in JIT | Shows the percentage of elapsed time the CLR spent in a Just in Time compilation phase. Should be relatively low, ideally below 20%. | Above this level can indicate that perhaps some code is being emitted and dynamically compiled by the application. Using the NGEN command-line tool against your application assemblies to create a native, pre-JIT compiled image for the target platform can reduce this. |
| .NET CLR Security | % Time in RT Checks | Represents the percentage of time spent performing Code Access Security (CAS) checks, should be very low, preferably zero | Exceeding 20%, can hamper system performance and cause excessive CPU utilization. This can often be caused by accessing resources across a network share or Storage Area Network where network credentials and security contexts need to be
evaluated to gain access to the resource. |
| .NET CLR Locks and Threads | Total # of Contentions | Represent the number of unsuccessful managed-lock acquisitions.
Total amount of unsuccessful lock acquisition attempts by threads managed by the CLR | When using the lock statement, System.Monitor.Enter statement, and the MethodImplOptions.Synchronized attribute. |
| .NET CLR Locks and Threads | Contention Rate / Sec | Represent the number of unsuccessful managed-lock acquisitions.
Amount/sec of unsuccessful lock acquisition attempts by threads managed by the CLR | Unsuccessful locks can cause
serious performance issues when the rate is high, as the threads are not only
synchronized but ultimately unsuccessful, potentially throwing exceptions and
waiting excessively. This rate should be very low, ideally zero. |