常说的数据库I/O

这是51cto上的一篇文章，下载下来的，看了觉得还是不错的，怕以后给搞丢了，就转到这里来了，方便以后看。     

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

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

　　对于数据库在日常应用中的特点，我们可以有很多想法。

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