Monday, August 18, 2014

Processor Performance Counter

CPU and Memory utilization are key metrics captured in any performance test. This post will be focusing on CPU utilization and dealing with CPU bottleneck.

Whenever we say CPU utilization for a CPU with configuration 4 GHZ with 1 core is 80% this mean that currently 3.2 billion cycles in a seconds. However this calculation is not that easy in normal case considering when we have multi cores, hyperthreading, virtualization, shared cache and other advancement going in infrastructure space.

For any loadtest run, following performance counters should be typically used

- % Processor Time_Total Instance - Percentage of elapsed time a CPU is busy executing a non-idle thread (An indicator or processor activity). 85% of processor utilization can be taken as a threshold value.

Normally, CPU utilization should increase as load is increased. If CPU utilization is not increased then we may have a bottleneck which will impact the throughout and response time. Underutilization normally happens when we have multiprocessor systems with one JVM. To take the advantages of most of the processing power we might like to consider more than one JVM


Sometimes, load test will show us spike/burst in CPU utilization. Understanding the reason behind burst will require additional metrics and counters.

- Processor\% User Time : This counter will helps us in identifying any high user mode processor bottleneck.

- % Privilege Time-Percent of threads running in privileged mode (file or network I/O, or allocate memory)

Processor % Privilege Time consistently over 75 percent indicates a bottleneck.

Processor Queue Length - Number of tasks ready to run than the processors can get to.
Processor Queue Length greater than 2 indicates a bottleneck. It would be good to check with the Dev/infra team about the value of thread pool and should it be increased or not.


System\Context Switches /sec. Occurs when higher priority threads preempts lower priority threads that are currently running, and can indicate when too many threads are competing for processor time. If much processor utilization is not seen and very low levels of context switching are seen, it could indicate that threads are blocked

As a general rule, context switching rates of less than 5,000 per second per processor are not worth worrying about. If context switching rates exceed 15,000 per second per processor, then there is a constraint.



No comments: