1. IO处理过程
磁盘IO进程会成为系统的一个瓶颈，特别是对于运行数据库的系统而言。数据从磁盘读取到内存，在到CPU缓存和寄存器，然后进行处理，最后写回磁盘，中间要经过很多的过程，下图是一个以write为例的 Linux 磁盘IO子系统的架构：
可以看到IO操作分成了四个层面：
1)文件系统缓存：处理数据必须先从磁盘读到缓存，然后修改，然后刷会磁盘。缓存的刷新涉及到两个参数：vm.dirty_background_ratio、vm.dirty_ratio。还有刷新写回时，使用到 bio 结构，bio的组成是由磁盘上相邻的block组成的，所以这里进行了优化。
2)block layer：该层就涉及到 IO调度算法，IO调度算法在mysql服务器是一个很重要的调优手段。系统中所有进程申请的IO操作，全部在这里进行排队，等待调度，然后写回磁盘。调度算法有四种：
1> Anticipatory: 适用于个人PC，单磁盘系统；
2> CFQ(Complete Fair Queuing)：默认的IO调度算法，完全公平的排队调度算法。每一个进程的IO请求会安排进一个专门的IO队列，然后按照进程组来公平的调度IO，也就是每一个进程组之间按照公平的方式来调度IO。显然他适合多用户的系统，但是极为不适合作为数据库系统的IO调度算法，因为显而易见，数据库系统中，数据库进程肯定是IO最多的一个进程组，然后它却只能获得和其它进程一样多的IO调度机会。所以显然这是极为不合理的。数据库系统绝对不要使用该调度算法。
3> Deadline: 按照截止期限来循环在各个IO队列中进行调度，所以它提供了一个近实时的IO系统，并且磁盘throughput也很好，也不会造成starvation.一般mysql系统建议采用该调度算法。
4> NOOP: 简单的FIFO队列进行调度，No operation的意思是，它没有进行额外的将临近的IO进行合并的操作，所以它对CPU的使用极少。该调度算法特别适合于SSD。因为SSD在对待顺序IO和随机IO没有什么区别。所以它不需要对临近的IO进行合并。避免了合并操作对CPU的使用。
所以一般而言，对于mysql的系统，如果是SSD，那么应该使用NOOP调度算法，如果是磁盘，就应该使用Deadline调度算法。
3)磁盘驱动层：对于顺序读系统而言，很容易在磁盘接口层的带宽上成为瓶颈所在；
4)磁盘：对于随机读多的系统而言，磁盘很容易成为瓶颈所在，一般的优化就是使用RAID或者换SSD；
2. IO瓶颈检测
iostat, sar, vmstat