性能各个指标分析

avg. disk queue length

avg. 平均queue 队列length 时长

它指的是“当前磁盘队列长度”,说的通俗点就是:数器反映磁盘完成请求所用的时间。较高的值表明磁盘控制器由于失败而不断重试该磁盘。这些故障会增加平均磁盘传送时间。

晕倒。怎么感觉像在给小学生讲课。打住。 ======================================补充,好吧,再说具体点。简单可以理解成磁盘数据吞吐量的外在体现。比如你在曲线上随便取两个不同的点,高的一点说明正在的进行读写操作的量比较大,反之,比较小。说道这个地步,已经没法在说了。

如何通过Performance Log确定SQL的磁盘有性能问题?

1. 查看Disk Bytes/sec. 举个例子, 这个counter的最大值如果是11M, 那么说明work load并不高.

2. 查看Avg. Disk sec/Transfer. 举例, 这个counter的推荐值是<0.015.

3. 查看Avg. Disk Queue Length, 这个推荐值是<2.

一些比较重要的performance counter:


Counter


Description


LogicalDisk\

% Free Space


报告磁盘空间中未被分配的空间占逻辑卷中总可用空间的百分比.

当选择_Total实例的时候, 该计数器会重新计算每个盘总和.

PhysicalDisk对象没有这个计数器.


LogicalDisk|PhysicalDisk\

Avg. Disk Bytes/Transfer


衡量输入/输出(I/O)操作的数据量的大小. 如果磁盘相对快速地传输大量数据, 那么磁盘是高效的.

当衡量最大吞吐量的时候, 应该观察这个计数器.

要进一步地分析数据传输, 应当查看Avg. Disk Bytes/Read 和Avg. Disk Bytes/Write两个计数器.


LogicalDisk|PhysicalDisk\

Avg. Disk sec/Transfer


标示着数据被移动的速度(以秒衡量). 衡量每次数据传输的平均时间, 而不论读或写的数据的大小. 它展示了从数据离开Diskperf.sys, 到操作完成的读或写的总时间.

这个计数器的高数值可能意味着系统因为队列太长而在重试请求, 或者由于不常见地磁盘错误而重试请求.

要进一步地分析数据传输, 应当查看Avg. Disk sec/Read 和Avg. Disk sec/Write两个计数器.


LogicalDisk|PhysicalDisk\

Avg. Disk Queue Length


记录了在计数器数据采样点之间的时间内被放入队列中等待磁盘的请求的数量, 也包括正在被处理的请求在内. 所以, 这有可能是有点夸大的数据.

如果有多于两个的请求持续地在一个单磁盘的系统中等待, 那么磁盘可能就是瓶颈.

要进一步地分析队列长度的数据, 应当查看Avg. Disk Read Queue Length 和Avg. Disk Write Queue Length两个计数器.


LogicalDisk|PhysicalDisk\

Current Disk Queue Length


标示着当前正在等待的磁盘请求的数量, 也包括正在被处理的请求.

受许多因素的影响, 除非工作量的状态比较稳定, 并且你收集了充足的采样, 才能建立一个模式.

这是一个即刻的数值或是当前队列的长度, 跟Avg. Disk Queue Length, Avg. Disk Read Queue Length, 和Avg. Disk Write Queue Length不一样, 那三个反应的是平均值.


LogicalDisk|PhysicalDisk\

Disk Bytes/sec


标示着字节被传输的速率, 该计数器是磁盘吞吐量的主要衡量指标.

要进一步地分析读或写的传输的数据, 应当分别查看Disk Read Bytes/sec 或Disk Write Bytes/sec两计数器.


LogicalDisk|PhysicalDisk\

Disk Transfers/sec


标示着每秒钟完成的读和写操作数, 而不论这些读写操作涉及到多少数据. 该计数器衡量磁盘的利用率.

如果该值超过50(如果是striped的分卷, 那就是看平均到每块物理磁盘上), 那么这可能就是一个瓶颈了.

要进一步地分析读或写的数据传输, 应当分别查看Disk Read/sec 和Disk Writes/sec


LogicalDisk\

Free Megabytes


汇报磁盘上没被分配的字节的量.

PhysicalDisk对象上, 没有这个计数器.


LogicalDisk|PhysicalDisk\

Split IO/sec


汇报操作系统将I/O请求分为多个磁盘请求的比率. 如果一个程序请求的数据大小太大, 以至于不能放在一个单个请求中, 或是磁盘有碎片, 那么一个split I/O请求可能会发生.

影响IO请求大小的因素可以包括应用程序设计, 文件系统, 驱动程序. 高比率的split I/O可能本身不会作为一个问题出现. 然而, 在单磁盘系统中, 这个计数器的高数值趋向于标志着磁盘碎片.


LogicalDisk|PhysicalDisk\

% Disk Time


报告选择的磁盘驱动器忙于服务读写请求的时间比率. 因为这个计数器的数据会跨越多个采样, 持续地夸大磁盘利用率, 那这个值跟%Idle Time比较, 这样能获得更清晰的认识.

默认这个计数器的值不会超过100%的.


LogicalDisk|PhysicalDisk\

% Disk Write Time


汇报被选择的磁盘忙于处理写请求所占的时间的百分比.


LogicalDisk|PhysicalDisk\

% Disk Read Time


汇报被选择的磁盘忙于处理读请求所占的时间的百分比.


LogicalDisk|PhysicalDisk\

% Idle Time


汇报磁盘系统没在处理任何请求, 而且没有任何工作在队列中的时间的百分比. 注意这个计数器和%Disk Time相加的时候可能结果不是100%, 因为%Disk Time可能会夸打磁盘的利用率.

参考资料:

Examining and Tuning Disk Performance

http://technet.microsoft.com/en-us/library/cc938959.aspx

时间: 2024-11-05 15:07:46

性能各个指标分析的相关文章

Android 应用开发性能优化完全分析

1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质博文网上也还是有很多的,譬如Google官方都已经推出了优化专题,我这里只是总结下自的感悟而已,若有得罪欢迎拍砖,我

【转】Android应用开发性能优化完全分析

http://blog.csdn.net/yanbober/article/details/48394201 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质博文网

转——Android应用开发性能优化完全分析

[工匠若水 http://blog.csdn.net/yanbober 转载请注明出处.] 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质博文网上也还是有很多的,

转:Android应用开发性能优化完全分析

转自:http://blog.csdn.net/yanbober/article/details/48394201 1 背景 其实有点不想写这篇文章的,但是又想写,有些矛盾.不想写的原因是随便上网一搜一堆关于性能的建议,感觉大家你一总结.我一总结的都说到了很多优化注意事项,但是看过这些文章后大多数存在一个问题就是只给出啥啥啥不能用,啥啥啥该咋用等,却很少有较为系统的进行真正性能案例分析的,大多数都是嘴上喊喊或者死记住规则而已(当然了,这话我自己听着都有些刺耳,实在不好意思,其实关于性能优化的优质

【MySql】性能优化之分析命令

[MySql]性能优化之分析命令     一 当发现程序运行比较慢的时候,首先排除物力资源问题之后,就将注意力转向mysq数据库: 1.首先确定运行慢的sql语句: mysql> show full processlist; 2.确认低效的查询: 多次执行第一步发现time耗费大的sql语句.查看耗费的时间. 3.为sql生成一个执行计划query Execution plan(QEP) mysql> explain select * from tbal_name where ...; 4.查

转:使用xhprof进行线上PHP性能追踪及分析

原文来自于:http://avnpc.com/pages/profiler-php-performance-online-by-xhprof 原创作者:AlloVince 之前一直使用基于Xdebug进行PHP的性能分析,对于本地开发环境来说是够用了,但如果是线上环境的话,xdebug消耗较大,配置也不够灵活,因此线上环境建议使用xhprof进行PHP性能追踪及分析. xhprof的安装与简易用法 xhprof是Facebook开源的轻量级PHP性能分析工具,Linux环境下可以通过pecl直接

PHP性能追踪及分析工具xhprof的安装与使用

https://segmentfault.com/a/1190000007288664(原文地址) 对于本地开发环境来说,进行性能分析xdebug是够用了,但如果是线上环境的话,xdebug消耗较大,配置也不够灵活,因此线上环境建议使用xhprof进行PHP性能追踪及分析. 我们今天就简单介绍一下xhprof的简单安装与使用 xhprof的安装 下载xhprof,我们这里选择的是通过git clone的方式,当然你也可以从 http://pecl.php.net/package/x... 这里下

Redis集群性能问题深度分析

Redis集群性能问题深度分析 参考 Redis开发与运维 https://redis.io/ http://www.redis.cn/ https://github.com/antirez/redis https://github.com/sohutv/cachecloud 源起 优化之路永无止境,在此之前一做过一些架构优化汇总如下: 1,Redis集群3.0.7升级到3.2.9解决读从节点KEY过期不删除问题,集群有几千万KEY原来经核查3.0.7版本只有主上保存过期时间,所以需要主触发才能

使用Django.core.cache操作Memcached导致性能不稳定的分析过程

使用Django.core.cache操作Memcached导致性能不稳定的分析过程 最近测试一项目,用到了Nginx缓存服务,那可真是快啊!2Gb带宽都轻易耗尽. 不过Api接口无法简单使用Nginx缓存,使用Memcached作二级缓存.但发现性能非常之不稳定,最终发现问题出在Memcached上.大压力时Memcached无法连接,即使使用Telnet也连接超时/连接被拒绝. 与开发沟通后发现用的django.core.cache操作Memcached,于是要求使用其它库取代,选中pyth