前言
本文基于文件系统和磁盘I/O工作原理，通过典型I/O问题分析，总结磁盘I/O调优的一般套路。
问题描述：文件读取操作导致进程CPU偶尔飙高？
原因分析：
1、先通过 top命令，观察机器整体cpu使用情况，重点观察应用进程cpu，发现应用进程cpu偶尔会飙高到800%或更高，每次飙高伴随着sy占用过多，说明cpu消耗到系统内核操作。由于应用主要做了文件读取操作，因此怀疑读取文件的算法过多的消耗了内核cpu。
2、进一步使用 vmstat -w -S m 1 观察，当进程未启动前，bi为0；进程启动后，bi、in和cs均增大后稳定下来。每当应用进程的cpu飙高时，伴随着系统sy占用过高，同时proc r 队列待处理任务数增大。由此猜测是文件读操作引起了过多内核cpu占用及cpu任务处理不及时现象。
3、基于以上分析，查看程序文件读取方法，采用了org.apache.commons.io.LineIterator底层是一个默认8k缓冲区的文件输入流，对应操作系统的应该是一个BIO的系统函数调用。
I/O流程如下：
基于I/O流程图分析，BIO函数调用，会导致频繁的上下文切换（数据从内核空间copy到用户空间）、平均负载升高（proc增大），由于其发生在内核态，因此sy所占cpu升高。
优化方案：
NIO：基于Buffer缓冲区，非阻塞的读取方式，本质上是通过减少函数调用次数降低内核到用户空间的拷贝次数。（优化空间有限）
mmp：则采用文件内存直接映射的方式，避免了数据从内核到用户空间的拷贝。（理论上优化空间较大）
方案替换：
将文件读取算法采用mmp实现，并替换后。vmstat -w -S m 1 观察，发现随着bi升高稳定后，cs和in稳定后的值较之前有明显减少，且proc r 队列不再出现过高、sy占用也稳定正常。
结论：问题产生的根本原因是大量的BIO请求，过度消耗了系统内核sy，至使cpu竞争（任务处理不及时proc r 增大）出现。
新的问题产生： 替换方案（mmp）读取文件，进程cpu正常，可系统wa较之前有明显增大？
原因分析：
1、通过 vmstat -w -S m 1 观察，发现系统proc b队列中有等待处理的任务，同时wa升高，怀疑是io瓶颈。
2、进而通过 iostat -x 1 观察本机I/O整体情况，I/O使用率（%util ）不高，读的IOPS即rkB/s是我的应用消耗的，而写的IOPS即wkB/s是本机其他进程共同消耗。观察发现，当大量写操作发生，即wkB/s上升到2万以上时，就会伴随着I/O使用率瞬间上升至80%左右，r_await 、w_await 也有不同程度上升。与此同时 vmstat -w -S m 1 显示指标wa 上升，proc b队列中也开始有等待任务出现。可见本机的读和写应用导致I/O瓶颈出现。
优化方案：通过程序控制读的速度，降低I/O竞争。
结论： 通过控制文件读的速度，有效降低了本机整体I/O。
调优的一般步骤：
a、先通过top 、vmstat、iostat 观察整体机器状况。
b、再通过 pidstat 进一步明确I/O问题产生的进程。
c、针对问题进程分析I/O行为。
总结：
1、文件I/O应谨慎使用BIO方式，大量的I/O请求会造成上下文切换及中断处理过多，占用过多的sy系统cpu，进而引发proc r队列中任务处理不及时等cpu竞争问题。
2、大量I/O会导致I/O性能瓶颈，应使用阀值变量控制进程读写频率，降低I/O发生瓶颈的概率。
3、尽量使用NIO或mmp方式代替传统BIO的I/O操作方式。
