Observing Processor Queue Length
A collection of one or more threads that is ready but not able to run on the processor due to another active thread that is currently running is called the processor queue. The clearest symptom of a processor bottleneck is a sustained or recurring queue of more than two threads. Although queues are most likely to develop when the processor is very busy, they can develop when utilization is well below 90 percent. This can happen if requests for processor time arrive randomly and if threads demand irregular amounts of time from the processor. For more information about monitoring and adjusting thread scheduling, see "Threads in a Bottleneck" later in this chapter.
The System\Processor Queue Length counter shows how many threads are ready in the processor queue, but not currently able to use the processor. Figure 7.2 shows a sustained processor queue with utilization ranging from 60 to 90 percent. Notice that the default scale for the Processor Queue Length counter value is 10. Therefore, System Monitor graphs a queue that is two threads long as 20. You can change the scale factor using the Data properties tab in System Monitor.
Figure 7.2 Sustained Processor Queue with Rising Processor Usage
In Figure 7.2, the line across the top represents Processor(_Total)\% Processor Time. The lower line is System\Processor Queue Length.
Figure 7.3 shows a sustained processor queue accompanied by processor use at or near 100 percent.
Figure 7.3 Sustained Processor Queue with Maximum Processor Usage
Figure 7.4 illustrates how a processor bottleneck interferes with your computer's performance. It shows that when a processor is already at 100 percent utilization, starting another process does not accomplish more work.
Figure 7.4 Saturated Processor
In Figure 7.4, the dark line running across the top of the graph is Processor(_Total)\% Processor Time. The line below it is System\Processor Queue Length. Midway through the sample interval, a process with three threads was started. The graph illustrates that the queue increased as a result of this added workload. Some of the threads of the added process might be in the queue, or they might be running, having displaced the threads of a lower-priority process. Nonetheless, because the processor was already at maximum capacity, it can accomplish no additional work.
If your system's counter values appear similar to those in Figure 7.4, this indicates a bottleneck. Logging, over time, will reveal any patterns associated with the bottleneck. For example, you might find that bottlenecks occur when certain processes are running or at a certain time of day. In this case, you might be able to eliminate the bottleneck by balancing the workload between computers—that is, running the process on another, less loaded computer.
However, if sustained queues appear frequently, you need to investigate the processes that are running when threads collect in the queue. To determine this:
| • |
Identify the processes that are consuming processor time. Determine whether a single process or multiple processes are active during a bottleneck. Running processes appear in the Instance box when you select the Process\% Processor Time counter. For more information, see "Processes in a Bottleneck" later in this chapter. |
| • |
Scrutinize the processor-intensive processes. Determine how many threads run in the process and watch the patterns of thread activity during a bottleneck. |
| • |
Evaluate the priorities at which the process and its threads run. You might be able to eliminate a bottleneck merely by adjusting the base priority of the process or the current priorities of its threads. However, Microsoft does not recommend this as a long-term solution. Use Task Manager to find the base priority of the process. |
Note
Different guidelines apply for queue lengths on multiprocessor systems. For busy systems (those having processor utilization in the 80 to 90 percent range) that use thread scheduling, the queue length should range from one to three threads per processor. For example, on a four-processor system, the expected range of processor queue length on a system with high CPU activity is 4 to 12.
On systems with lower CPU utilization, the processor queue length is typically 0 or 1.
There are other objects that track processor queue length. The Server Work Queues\Queue Length counter reports the number of requests in the queue for the processor on the selected server. For more information about monitoring the Server Work Queues object, see "Monitoring Network Performance" in this book.
---------------------
真遺憾，看不到圖片，但是對於系統來說，這個Processor Queue越大，對硬件性能的考驗就越大，微軟在windows2000時推薦的是如下：
1。對於多核系統（〈=3CPUS）推薦值爲1-3
2。對於四核以及以上的，推薦值爲4-12
但是目前操作系統爲2003，CPU的硬件性能已經得到很大的提高，系統的處理能力也有所增強。所以該性能檢測的閾值可適當放大
但是放大閾值的最佳做法是什麼呢？
OPmanager給出一個說法：
It depends. Please run OpManager for a while, say about a week and find the average usage of any parameter being monitored. Then set a threshold
slightly above the average value. If we find any recommended value from Microsoft we will update you.
另外，我認爲：
緊緊靠系統的隊列平均數還是不夠的，還要查看你的CPU的利用率和內存的使用情況
故總結如下
1：檢查系統的CPU\MEM利用率，如果CPU利用率比較高\MEM比較高（同時大於50％）.隊列長度比較大的情況下，就要考慮升級硬件了
2：CPU利用率一般（目前的CPU處理能力得到很大的提升，問題一般不會出在這裏。）而內存的利用率比較高（70％），隊列長度大於10，就要考慮升級內存了。
3：如果CPU和MEM利用率都不高，可按照OPmanager推薦的做法來設置監控閾值