After you have identified a processor bottleneck, you need to determine whether a single process is using the processor or whether many running processes are consuming the processor. To do this, log the processor time for each process that is running on your computer as follows:
Select the Process object.
Select the % Processor Time counter.
Select each process instance.
IMPORTANTAll processes that are running appear in the Instance box listed by the name of the associated executable program (for example, Windows Explorer appears as "explorer" in the Instance box). Note that if you are running multiple instances of the same executable program, System Monitor lists these under the identical name; thus, you need to track these by their process identifiers. You can find the process identifier by using the Process Process ID counter or by adding the process identifier (PID) column in Task Manager. For more information, see "Threads in a Bottleneck" later in this chapter.
For more information about MS-DOS-based and 16-bit Windows-based processes that appear differently in the user interface, see "Overview of Performance Monitoring" in this book and also see Windows 2000 Server Help.
To determine the processing load generated by your typical workload, include the instances for the processes that you normally run. If you find that you don't normally use some processes (such as background services) that are already running, stop these processes and measure the impact on your processing load. This might be an easy way to improve your computer's processing efficiency. However, before doing so, make sure you understand the possible effects. To stop a service, complete the following procedure.
To stop a service
From the Start menu, point to Programs and Administrative Tools, and then click Computer Management.
In the Computer Management console, click Services and Applications.
Under Services and Applications, double-click Services.
Right-click the name of a service, and then click Stop.
If the threads of a process are using a high percentage of CPU time, you need to analyze the process to determine if the application's performance can be optimized. For information about improving application performance, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. If optimization does not yield satisfactory results, you need to add processor resources.
Device driver problems can cause high % Processor Time values for the System process.
If a single process is using the processor, the chart line associated with that process is the highest one in the graph, such as in Figure 29.6, which is an actual histogram of a processor bottleneck caused by a single process. By running CpuStress, a utility on the Windows 2000 Resource Kit companion CD, you can produce the results shown in this example.
Figure 29.6 Processor Bottleneck Caused by a Single Process
This histogram shows that a single process (represented by the tallest bar) is highly active during a bottleneck; its threads are running for more than 90 percent of the sample interval. If this pattern persists and a long queue develops, it is reasonable to suspect that the application running in the process is causing the bottleneck.
Note that a highly active process is a problem only if a queue is developing. If you are not satisfied with response time and throughput, you can choose to upgrade to a faster processor to achieve better performance.
If you suspect that an application is causing a processor bottleneck, stop using the application for a few days or move it to a different computer. Another option is to schedule the process to run outside of peak operating hours. Then log processor use again. If the problem disappears, it is likely that the application caused it.
Reducing Single-Process Bottlenecks
If you cannot use another computer and you have access to the application source code, you can tune the application to increase efficiency. Start by using a profiler, an analysis tool that you can use to examine the run-time behavior of your programs. Profiling enables you to analyze how the application is spending processor time. The Platform SDK includes tools and methods for profiling and optimizing applications, including instructions for developing performance counters to monitor the inner workings of your application. To tune an application to be less CPU-intensive, use SDK utilities such as Call Attributed Profiler (CAP) or File I/O Synchronization Win32 API Profiler (FIOSAP). You can also use API Monitor (Apimon.exe) and Kernel Profiler (Kernprof.exe.), which are included on the Windows 2000 Resource Kit companion CD.
If tuning efforts do not reduce the application's load on your processor, or if you do not have access to the application source code, you can:
Consider adding a processor or upgrading the one you have. If your application is multithreaded, adding a processor can alleviate a bottleneck because multithreaded applications can run on multiple processors. However, single-threaded applications do not benefit because the system cannot distribute their thread activity across processors; these applications need faster processors or need to run on a computer with extra processing capacity. Using a faster CPU will probably give you greater performance gain than installing additional processors because the management of the work performed by multiple CPUs also consumes processor time.
Investigate the activity of threads in the process. For more information about examining thread behavior and changing thread scheduling patterns to ensure that the necessary processes get processor time, see "Threads in a Bottleneck" later in this chapter. This section also contains instructions for determining whether a process is single-threaded or multithreaded; this distinction is important in making an upgrade decision.
If processor use continues to create a bottleneck even without the application that you first suspected, repeat the preceding steps and carefully monitor the processes that are active when the queues are longest.
Consider replacing the application with one that has been optimized to run under Windows 2000.
Figure 29.7 shows a histogram of processor time for many active processes. This example was produced by running two instances of CpuStress, which consumes processor cycles at the priority and activity levels that you specify.
Figure 29.7 Processor Time for Multiple Active Processes
In this example, two processes are consuming the processor while sharing it nearly equally. Although each process is using only 45 percent of the processor, the result is the same as a single process using 90 percent of processor time.
Figure 29.8 shows System Processor Queue Length during this bottleneck.
Figure 29.8 Processor Queue Length During Activity of Many Processes
In Figure 29.8, Processor % Processor Time for all processes is close to 100 percent during the sample interval. System Processor Queue Length reveals a long queue, averaging over six threads.
Figure 29.9 shows Task Manager during the same bottleneck. It shows that two CpuStress processes are each using about half of the time of the single processor on the computer. (Task Manager shows current values, so you need to watch the display to see changes in processor use for each process.)
Figure 29.9 CPU Usage for Multiple Processes in Task Manager
At this point, you can choose to add a processor or upgrade the one you have, or you can investigate the activity further by researching thread behavior. Although a faster processor might help this situation somewhat, multiple-process bottlenecks are best resolved by adding another processor. Multithreaded processes, including multithreaded Windows 2000 services, benefit the most from additional processors because their threads can run simultaneously on multiple processors. You might want to partition the processes among the processors for optimal efficiency. For more information, see "Measuring Multiprocessor System Activity" in the Server Operations Guide.
To find out more about how a particular process uses the processor, examine the Process % User Time and Process % Privileged Time counters, followed by Thread object counters, as described in the following section.
For more information about determining if your application is multithreaded, see "Threads in a Bottleneck" later in this chapter. You might also want to find out whether all threads in a multithreaded process are active during bottlenecks. The benefit of adding processors depends on whether you have a lot of active threads. You could find, as a result of monitoring, that threads in a process are inactive most of the time, so adding a processor to handle these inactive threads is a waste of money and capacity.
For more information about the benefits of adding processors to manage a larger workload (called scaling) and how to determine whether scaling is appropriate, see "Measuring Multiprocessor System Activity" in the Server Operations Guide.