通常，我们很容易观察到数据库服务器的内存和CPU压力。但是对I/O压力没有直观的判断方法。
磁盘有两个重要的参数： Seek time、 Rotational latency。正常的I/O计数为：①1000/(Seek time+Rotational latency)*0.75，在此范围内属正常。当达到85％的I/O计数以上时则基本认为已经存在I/O瓶劲。
理论情况下，磁盘的随机读计数为125、顺序读计数为225。对于数据文件而言是随机读写，日志文件是顺序读写。因此，数据文件建议存放于RAID5上，而日志文件存放于RAID10或RAID1中。
下面假设在有4块硬盘的RAID5中观察到的Physical Disk性能对象的部分值：
- Avg. Disk Queue Length 12
- Avg. Disk Sec/Read .035
- Avg. Disk Sec/Write .045
- Disk Reads/sec 320
- Disk Writes/sec 100
- Avg. Disk Queue Length，12/4=3，每块磁盘的平均队列建议不超过2。
- Avg. Disk Sec/Read一般不要超过11～15ms。
- Avg. Disk Sec/Write一般建议小于12ms。
从上面的结果，我们看到磁盘本身的I/O能力是满足我们的要求的，原因是因为有大量的请求才导致队列等待，这很可能是因为你的SQL语句导致大量的表扫描所致。在进行优化后，如果还是不能达到要求，下面的公式可以帮助你计算使用几块硬盘可以满足这样的并发要求：
- Raid 0 -- I/Os per disk = (reads + writes) / number of disks
- Raid 1 -- I/Os per disk = [reads + (2 * writes)] / 2
- Raid 5 -- I/Os per disk = [reads + (4 * writes)] / number of disks
- Raid 10 -- I/Os per disk = [reads + (2 * writes)] / number of disks
我们得到的结果是：(320+400)/4=180，这时你可以根据公式①来得到磁盘的正常I/O值。假设现在正常I/O计数为125，为了达到这个结果：720/125=5.76。就是说要用6块磁盘才能达到这样的要求。
但是上面的Disk Reads/sec和Disk Writes/sec是个很难正确估算的值。因此只能在系统比较忙时，大概估算一个平均值，作为计算公式的依据。另一个是你很难从客户那里得到Seek time、Rotational latency参数的值，这也只能用理论值125进行计算。
如何通过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可能会夸打磁盘的利用率. |
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持脚本之家。