关于系统处理能力问题(Observing Processor Queue)
2012-04-26 11:49
309 查看
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 sustainedor 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推荐的做法来设置监控阈值
相关文章推荐
- 关于系统处理能力问题(Observing Processor Queue
- 关于SQL处理能力的问题
- 关于申报系统存在问题的处理
- 关于部分手机调用系统拍照和相册图片出现旋转问题处理
- 系统设计时关于性能问题处理的几点心得
- 关于HttpQueue 处理具有大量数据访问系统的工具
- 系统设计时关于性能问题处理的几点心得
- 关于COM Surrogate已经停止工作的问题的处理
- Linux系统关于ACM时间的使用和文件目录的权限的问题
- Ubuntu -- Ubuntu系统问题处理大全(持续 更新)
- (干货)DB2中关于百分号%的转义处理问题
- 用PRINTF 和defineDEBUG条件编译来处理系统出错的问题
- Java实现超市管理系统Class思维模式实现,空指针问题常见处理办法
- 关于处理字符串里姓名中间、前后有空格的问题
- 关于wind7重新安装系统后,连接mysql的问题
- Hadoop关于处理大量小文件的问题和解决方法
- 郑州iOS點 - 关于升级Mac系统后cocoapods无法导入第三方的问题解决办法
- 整合公司业务系统,处理微服务事务不一致的问题
- 深入解析:分布式系统的事务处理经典问题及模型(转载分享)
- 关于文件系统的问题