51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 12306|回复: 37
打印 上一主题 下一主题

[原创] 简单判断CPU瓶颈(图)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2008-4-20 16:53:52 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
简单判断CPU瓶颈(图)





1、System %total processor time该值持续超过90%。一种情况特殊:多CPU系统中,数据本身不大,但CPU之间负载状况极不平衡的情况。

2、其次看processor%processor time 和 Processor %user Time 和 processor %privileged Time.

Processor %user Time,如果该值大,考虑能过算法优化等改善这个值。如果是数据库服务器,可能数据库排序或是函数操作消耗了过多的CPU时间。

3、看System/%processor Queue Length的值,当该计数器的值大于CPU数量总数+1时,说明处理器阻塞。

4、多处理器中,%DPC Time的值大于50%,且processor%processor time非常高,则加入网卡可能会提高性能。

[ 本帖最后由 tiannianyong 于 2008-10-22 14:50 编辑 ]

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?(注-册)加入51Testing

x
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏1
回复

使用道具 举报

  • TA的每日心情
    开心
    2014-12-26 13:34
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    2#
    发表于 2008-4-21 09:14:48 | 只看该作者

    可以这么理解。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2008-4-21 09:23:21 | 只看该作者

    这是专门软件吗?

    这个界面很清晰,确实能比较直接地判断;但怎么好像没见过,是我孤陋了。。。。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    4#
    发表于 2008-4-21 09:37:12 | 只看该作者
    这是loadrunner的analysis,怎么能没见过
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2008-4-21 11:05:42 | 只看该作者
    %processor time的平均值大于95  可图上%processor time 的平均值不是21.383吗?
    processor queue length 的平均值是2.447
    这样的话也能判定是CPU瓶颈的问题吗? 谢谢
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
     楼主| 发表于 2008-4-22 14:03:38 | 只看该作者

    回复 4# 的帖子

    因为我的CPU是笔记本上的双核的,所以达不到95%以上,你只可想象即可,就像图的左边说明的部分,谢谢!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2008-4-23 22:23:30 | 只看该作者
    不错,正在学习中...
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2008-4-24 01:04:31 | 只看该作者
    很多国外的技术资料从2个方面考虑资源负荷状况
    1) 利用率
    2) 饱和程度。就是排队情况

    楼主注意到2个层面的东西,很好。

    有时候还需要检查是否由于IO 或者内存不足导致CPU堆积
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2008-4-24 11:09:20 | 只看该作者
    bucuo
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2008-4-24 11:40:16 | 只看该作者
    我怎么觉得测试的时候经常会有排队>cpu个数的情况啊?~~
    难道是机器太差了。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2008-4-24 11:58:22 | 只看该作者
    关注中
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-6-20 12:33:41 | 只看该作者
    原帖由 laipi 于 2008-4-21 11:05 发表
    %processor time的平均值大于95  可图上%processor time 的平均值不是21.383吗?
    processor queue length 的平均值是2.447
    这样的话也能判定是CPU瓶颈的问题吗? 谢谢



    如果一直保持,就对了

    CPU跟不上了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2008-6-20 13:30:29 | 只看该作者
    谢谢了,学习中。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2019-9-27 12:46
  • 签到天数: 179 天

    连续签到: 1 天

    [LV.7]测试师长

    14#
    发表于 2008-6-20 13:43:57 | 只看该作者
    楼主图中这个情况算是cpu瓶颈吗?

    %processor time的平均值没有达到95阿
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2019-9-27 12:46
  • 签到天数: 179 天

    连续签到: 1 天

    [LV.7]测试师长

    15#
    发表于 2008-6-30 17:40:04 | 只看该作者
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2008-6-30 20:32:56 | 只看该作者
    其实这只是一种情况,不能完全说明是CPU瓶颈,我现在测的系统服务器8核,10+G的内存,测试的过程中8核都%95以上,队列平均能到5至6,这种变态服务器已经不能说是CPU瓶颈这么简单的问题了,其实是把复杂运算放在数据库端导致高的CPU利用率,不知道liangjz版有什么看法
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2008-6-30 21:28:00 | 只看该作者
    仅以此图来看,不能说明是CPU的瓶颈。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2008-10-16 11:35:07 | 只看该作者
    对于整个系统的性能来讲,CPU确实是它的瓶颈。
    但是CPU瓶颈不见得就说明硬件配置不足,也可能是在程序在调用的过程中申请资源之后没能及时释放,而引起了可用资源的不足呢?

    本人拙见,请大家指点呢!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2008-10-16 14:19:49 | 只看该作者
    关于Processor Queue Length计数器的说明:

    Processor Queue Length 是处理器队列的线程数量。与磁盘计数器不同,此计数器只显示就绪线程,而不是正在运行的线程。即使运行多处理器的计算机只有一个处理器队列。因此,如果一台计算机有几个处理器,您需要将此值除以处理工作量的处理器数量。每个处理器,不管工作量大小,如果保持 10 个以下线程的处理器队列,通常是可以接受的。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2008-10-18 08:53:18 | 只看该作者

    新人请教

    请问楼主那个CPU的利用率五十个用户是68%一百个用户是73%这个是怎么算出来的。谢谢赐教了,
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-16 20:22 , Processed in 0.088194 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表