关于系统处理能力问题（Observing Processor Queue)

 

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推荐的做法来设置监控阈值