WINDOWS 1002000 PROFESSIONAL RESOURCE KIT [Electronic resources] نسخه متنی

Threads in a Bottleneck

Investigate the individual thread or threads of the process or processes running during a bottleneck to understand more about the activity consuming the processor. Monitor the following factors to understand how thread activity is contributing to the problem and whether the cause is a single process or multiple processes:

The number of threads in each process that is running during a bottleneck.

The amount of processor time a thread is consuming.

The priority level at which threads are scheduled to run.

The amount of time the threads are using the processor in privileged mode.

You can use performance counters to analyze thread activity and adjust thread scheduling to allow more processor time for bottlenecked processes.

Apart from adjusting the thread's scheduling priority, you cannot alter thread behavior without changing the program code of the associated application. However, if you have access to application source code, you can write counters to monitor thread activity at a lower level. For more information, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

Single vs. Multiple Threads in a Bottleneck

Bottlenecks can result from activity of multiple threads in a single process, single threads in multiple processes, or multiple threads in multiple processes. Because these problems require different solutions, you need to first distinguish their causes.

To study threads during a bottleneck, log counters of the Processor, Process, and Thread objects for several days at an update interval of 60 seconds. This allows you to look at thread activity during typical operating conditions and helps you associate that activity with processor usage.

IMPORTANT

---

Performance counter values for threads are subject to error when threads are stopping and starting. Faulty values sometimes appear as large spikes in the data. For more information, see "Overview of Performance Monitoring" in this book.

To determine whether a process is single threaded or multithreaded

Right-click the Windows task bar and then click Task Manager.

In Task Manager, click the Processes tab, and from the View menu, click Select Columns.

In the Select Columns check box, select Thread Count, and then click OK.

This column shows the total number of threads associated with the process.

Figure 29.10 illustrates how Task Manager displays the number of threads running in a process and the name of the process.

Figure 29.10 Number of Threads Initiated by a Process Shown in Task Manager

In System Monitor or in Counter Logs, select the Thread object and look at all instances listed in the Instance box. If there are several thread identifiers (IDs) listed, then the process is multithreaded. Figure 29.11 illustrates multiple threads of a process as they are listed in the Instances box in the System Monitor user interface.

Figure 29.11 Thread Instances Shown When Adding Counters in System Monitor

System Monitor identifies threads by process name and thread number. The order in which the threads appear on the chart depends on the order in which you add them to your chart. The thread number shown in the Instance box represents the order in which the threads started, and it can change even as the process runs.

Thread identifiers are valid only during the lifetime of the thread; they are recycled when the thread terminates. Thread numbers can change while running, so it is best to monitor by thread identifier. The Task List Viewer (Tlist.exe) utility provides thread identifier information. For information about Tlist.exe, see Windows 2000 Support Tools Help. For information about installing and using the Windows 2000 Support Tools and Support Tools Help, see the file Sreadme.doc in the SupportTools folder of the Windows 2000 operating system CD.

If a process is multithreaded, adding a processor improves performance. If it is single threaded, you can improve performance by using a faster processor. These solutions are more advanced and more relevant to developers who also might want to tune the problem applications.

Charting Processor Usage Per Thread

Observing processor time by threads in a process provides additional information about the activity of the processor during a bottleneck. System Monitor provides the Thread % Processor Time counter for monitoring processor usage for each thread in a running process. If you have determined that a process is single threaded, you do not need to track the processor time for the process's thread because it will be nearly identical (except for small variations due to sampling) to the processor time you recorded when tracking the process itself.

Figure 29.12 shows Thread % Processor Time for all initialized threads during a bottleneck. Each bar of the histogram represents the processor time of a single thread.

Figure 29.12 View of Threads and Processor Usage

Figure 29.12 shows that the three threads of the CpuStress process are dominating the pattern of processor use, although a few other threads are getting some processor time.

If your thread activity appears similar to the preceding figure and a long queue is developing, some applications on your system are probably not getting enough processor time to run as efficiently as you would like. To investigate the threads of the process and how they use the processor, monitor context switching and user-mode versus kernel-mode CPU usage, as described in the following sections.

Context Switches

The Thread Context Switches/sec counter in System Monitor provides another perspective on how the operating system schedules threads to run on the processor. A context switch occurs when the kernel switches the processor from one thread to another. A context switch might also occur when a thread with a higher priority than the running thread becomes ready or when a running thread must wait for some reason (such as an I/O operation). The Thread Context Switches/sec counter value increases when the thread gets or loses the time of the processor.

In the course of a context switch, at least two threads are changing their thread state. However, one of the threads might be the idle thread of a given processor. A careful examination of context switch data reveals the patterns of processor use for a thread and indicates how efficiently a thread shares the processor with other threads of the process or other processes.

The System Context Switches/sec counter that reports systemwide context switches must be close to, if not identical to, the value provided by the _Total instance of the Thread Context Switches/sec counter. Monitoring over time can help you determine the range by which the two counters' value might vary.

Interpret the data cautiously. A thread that is heavily using the processor lowers the rate of context switches because it does not allow much processor time for other processes' threads. A high rate of context switching means that the processor is being shared repeatedly-for example, by many threads of equal priority. It is a good practice to minimize the context switching rate by reducing the number of active threads on the system. The use of thread pooling, I/O completion ports, and asynchronous I/O can reduce the number of active threads. Consult your in-house developers or application vendors to determine if the applications you are running provide tuning features that include limiting the number of threads.

A context switching rate of 300 per second per processor is a moderate amount; a rate of 1000 per second or more is high. Values at this high level might be a problem.

You can determine whether context switching is excessive by comparing it with the value of Processor % Privileged Time. If this counter is at 40 percent or more and the context-switching rate is high, then you can investigate the cause for the high rates of context switches.

User Mode and Privileged Mode

You can determine the percentage of time that threads of a process are running in user and privileged mode. User mode is the processing mode in which applications run. Privileged or kernel mode is the processing mode that allows code to have direct access to all hardware and memory in the system. Developers might want to know how much time a process is spending in each mode and what function is using the processor in this way.

I/O operations and other system services run in privileged (kernel) mode; user applications run in user mode. Unless they are graphics-intensive or I/O-intensive (such as file and print services), most applications should not be processing much work in kernel mode.

System Monitor has % Privileged Time and % User Time counters on the System, Processor, Process, and Thread objects. These counters are described in "Processor Counters" earlier in this chapter. System Calls/sec is also a useful indicator of privileged time usage because application calls to the operating system are handled in privileged mode.

In the user time and privileged time counters, System Monitor displays the percentages of total processor time that the process is spending in user or privileged mode.

Figure 29.13 is a System Monitor report on the amount of user and privileged time for three processes.

Figure 29.13 User and Privileged Time for Processes

In Figure 29.13, Microsoft® Management Console (MMC), the process in which System Monitor is running, is running mainly in privileged mode. Taskmgr.exe, the Task Manager process, is also running mainly in privileged mode , though this proportion varies significantly as the process runs. In contrast, Cpustres, the process for the CpuStress test program, runs entirely in user mode all of the time.

Figure 29.14 shows the amount of user and privileged time for each thread of the Task Manager process.

Figure 29.14 User and Privileged Time for a Process and Its Threads

The Process Viewer (Pviewer.exe) utility displays the amount of user time and privileged time for each running process and for each thread in the process. In Process Viewer, the user and privileged mode percentages for each process always total 100 percent because idle time is included. However, in System Monitor the percentages for each process reflect the amount of nonidle processor time actually used in each mode and instead total the amount of nonidle time. Therefore, the value for each process might not total 100 percent. To see the process times add up to 100 percent, combine the percentages for all processes including the Idle process.

For information about Pviewer.exe, see Windows 2000 Support Tools Help. For information about installing and using the Windows 2000 Support Tools and Support Tools Help, see the file Sreadme.doc in the SupportTools folder of the Windows 2000 operating system CD.