There are two different states to be aware of when talking about processors executing instructions: Privileged mode and User mode. Some operating system threads and interrupts (including all device driver functions) as well as Kernel-mode threads execute in privileged mode. User mode is where program threads from applications and services execute. User-mode threads cannot access system memory locations and perform OS functions directly. So looking at this in the context of our post on Processor Bottlenecks, let's take a look at the relevant Performance Monitor counters.
The first one to consider is Processor (n) \ % Privileged time. As the counter name suggests this indicates the percentage of the time in which the system was executing in Privileged mode. When dealing with Privileged mode operations, there are two modes to consider - Interrupt mode and Deferred Procedure Call (DPC) mode. Interrupt mode is reserved for interrupt service routines which are device driver functions.
When looking at this in Performance Monitor, % Interrupt Time is the time the processor spends receiving and servicing hardware interrupts during sample intervals. This value is an indirect indicator of the activity of devices that generate interrupts, such as the system clock, the mouse, disk drivers, data communication lines, network interface cards and other peripheral devices. These devices normally interrupt the processor when they have completed a task or require attention. Normal thread execution is suspended during interrupts. Most system clocks interrupt the processor every 10 milliseconds, creating a background of interrupt activity. DPC mode is time spent in routines known as deferred procedure calls - these are routines scheduled by device drivers to complete interrupt processing. DPC's are often referred to as soft interrupts. From the Performance Monitor perspective, the % DPC Time counter shows the percentage of the time that the system was executing in DPC mode. Measuring these counters separately can provide insight into whether there are issues with the interrupt service routine or its DPC.
Moving on to User mode, the Processor (n) \ % User time records the percentage of the time that the system is executing in User mode. Remember that when looking at these counters in Performance Monitor, the proportion of % Privileged Time to % User Time will depend on the system's workload. A couple of common misconceptions are that there will be a balance between these two areas, and that each system will look the same. That having been said, a system performing the same workload over time should show little change in the ratio of Privileged to User time. A general guideline is that the relative proportion of time spent in Interrupt mode is normally quite small. This is dictated by the network and disk interrupt rates.
So, for example, if you noticed that the % Interrupt Time counter is much higher now than your baseline, you may have a problem with a device driver or piece of hardware. Comparing the Interrupts / sec counter between the baseline and your current performance log, if the current rate is proportional to the level in the baseline, then the device driver code is the most likely culprit. If the Interrupt rate is significantly higher, you are probably experiencing a hardware issue. There is another tool, Kernrate, that can be used to narrow down the specific device. We'll cover Kernrate in a future post.
Conversely, if the bulk of the time is spent in User mode processing, you should start looking at which individual processes are consuming the CPU. For Privileged mode processing, you may not find a clear relationship to any specific process. However, because both User mode and Privileged mode processing are broken out at the process level, there is still value in examining the process counter even if the concern is excessive Privileged mode execution time.
This is where having a baseline of the server performance comes into play - if you compare the current behavior to the baseline (and this holds true for almost everything to do with Performance Monitoring) it becomes easier to identify the deltas which should help isolate changes that have occurred in the interim that could be causing any issues. And that wraps up this post. Until next time ...
| Share this post : |
|
|
|
|
|