LINUX磁盘IO调优指标

磁盘 I/O 性能监控的主要指标介绍如下：
指标 1：每秒 I/O 数（IOPS 或 tps）
对于磁盘来说，一次磁盘的连续读或者连续写称为一次磁盘 I/O, 磁盘的 IOPS 就是每秒磁盘连续读次数和连续写次数之和。当传输小块不连续数据时，该指标有重要参考意义。
指标 2：吞吐量（Throughput）
指硬盘传输数据流的速度，传输数据为读出数据和写入数据的和。其单位一般为 Kbps, MB/s 等。当传输大块不连续数据的数据，该指标有重要参考作用。
指标 3：平均 I/O 数据尺寸
平均 I/O 数据尺寸为吞吐量除以 I/O 数目，该指标对揭示磁盘使用模式有重要意义。一般来说，如果平均 I/O 数据尺寸小于 32K，可认为磁盘使用模式以随机存取为主；如果平均每次 I/O 数据尺寸大于 32K，可认为磁盘使用模式以顺序存取为主。
指标 4：磁盘活动时间百分比（Utilization）
磁盘处于活动时间的百分比，即磁盘利用率，磁盘在数据传输和处理命令（如寻道）处于活动状态。磁盘利用率与资源争用程度成正比，与性能成反比。也就是说磁盘利用率越高，资源争用就越严重，性能也就越差，响应时间就越长。一般来说，如果磁盘利用率超过 70%，应用进程将花费较长的时间等待 I/O完成，因为绝大多数进程在等待过程中将被阻塞或休眠。
指标 5：服务时间（Service Time）
指磁盘读或写操作执行的时间，包括寻道，旋转时延，和数据传输等时间。其大小一般和磁盘性能有关，CPU/ 内存的负荷也会对其有影响，请求过多也会间接导致服务时间的增加。如果该值持续超过 20ms，一般可考虑会对上层应用产生影响。
指标 6：I/O 等待队列长度（Queue Length）
指待处理的 I/O 请求的数目，如果 I/O 请求压力持续超出磁盘处理能力，该值将增加。如果单块磁盘的队列长度持续超过 2，一般认为该磁盘存在I/O性能问题。需要注意的是，如果该磁盘为磁盘阵列虚拟的逻辑驱动器，需要再将该值除以组成这个逻辑驱动器的实际物理磁盘数目，以获得平均单块硬盘的I/O 等待队列长度。
指标 7：等待时间（Wait Time）
指磁盘读或写操作等待执行的时间，即在队列中排队的时间。如果 I/O 请求持续超出磁盘处理能力，意味着来不及处理的 I/O 请求不得不在队列中等待较长时间。

通过监控以上指标，并将这些指标数值与历史数据，经验数据以及磁盘标称值对比，必要时结合 CPU、内存、交换分区的使用状况，不难发现磁盘 I/O潜在或已经出现的问题。但如果避免和解决这些问题呢？这就需要利用到磁盘 I/O性能优化方面的知识和技术。限于本文主题和篇幅，仅列出一些常用的优化方法供读者参考：

1.调整数据布局，尽量将 I/O 请求较合理的分配到所有物理磁盘中。
2.对于 RAID 磁盘阵列，尽量使应用程序 I/O 等于条带尺寸或者为条带尺寸的倍数。并选取合适的 RAID 方式，如 RAID10，RAID5。
3.增大磁盘驱动程序的队列深度，但不要超过磁盘的处理能力，否则，部分 I/O 请求会因为丢失而重新发出，这将降低性能。
4.应用缓存技术减少应用存取磁盘的次数，缓存技术可应用在文件系统级别或者应用程序级别。
5.由于多数数据库中已包括经优化后的缓存技术，数据库 I/O 宜直接存取原始磁盘分区（raw partition）或者利用绕过文件系统缓存的 DIO 技术（direct IO）

　目前web的应用大多都以I/O密集型为主，而存储技术的发展远没有计算机中其他系统发展迅速，尽管也有不少高端存储设备，但是价格的昂贵，不是一般大众能享受的起的。而基于现状更多是我们使用一般SAS盘结合应用使用不同的RAID组合，来实现我们平民化存储，为了得到更好的性能，那么和I/O相关的调整优化是必不可少的。

　　对于我们数据库调优来说，磁盘io优化是首屈一指的调优重点，我们都知道木桶原理，短板绝对整体的好坏，而数据库系统中这个短板正是由于我们使用的硬件设备里最弱的磁盘所导致。很多时候，我们会发现系统中io累得要死，而CPU却在那里空闲等待，主要是由于io执行响应时间太长，处理读写的速度远远赶落后于CPU的处理速度，这时我们会尽可能的让操作放到内存中进行，由磁盘与CPU的关系，转变成内存与CPU的关系。但是，我们始终不能回避磁盘io的弱点，优化是必须的。

　　对于数据库在日常应用中的特点，大致可以有这么些思路：

　　1. 随机读写的负载可以通过增加硬盘的个数实现扩展。

　　2. 对于顺序读写带来的压力，可以通过选择带宽相对高一些的磁盘来解决。

　　3. RAID 5和RAID 10都是不错的原则对于数据库应用来说。

　　4. 当然，基于自身业务的关键程度与成本双重考虑，Fusion-io卡(读与写的性能俱佳)和SSD(优秀的随机读)，都未尝不是一个理想的选择。

　　5. 在操作系统中，I/O Scheduler的调度模式选择deadline对于数据库应用是有利的。命令：echo deadline > /sys/block//queue/scheduler

　　6. 操作系统中nr_requests参数，可以提高系统的吞吐量，似乎越大越好，但是该请求队列的也不能过大，因为这样会消耗大量的内存空间。该值的调整需要综合多处因素，比如： 文件系统、sheduler类型、io的特点。命令： echo xxx > /sys/block//queue/nr_requests，nr_requests的大小设置至少是/sys/block//device/queue_depth的两倍，所以，修改nr_requtests的时候要注意。

　　7. 系统目录/sys/block/$disk/queue下还有一个预读的参数read_ahead_kb，这个参数增大只会对顺序读的操作有提升，而数据库这类应用中多数是随机读;通过命令hdparm -t /dev/sda{,,}可以测试修改后预读的效果。