原文地址：http://blog.chinaunix.net/uid-26922071-id-3954900.html
IO之流程与buffer概览
为了说明这个流程，还是用图来描述一下比较直观。
IO之内核buffer----"buffer cache"
"buffer cache"
要理解"buffer cache"这个东西，需要澄清一下概念：
一般情况下，进程在io的时候，要依赖于内核中的一个buffer模块来和外存发生数据交换行为。另一个角度来说，数据从应用进程自己的buffer流动到外存，中间要先拷贝到内核的buffer中，然后再由内核决定什么时候把这些载有数据的内核buffer写出到外存。
"buffer cache"仅仅被内核用于常规文件(磁盘文件)的I/O操作。
内核中的buffer模块，就是今天的主题----"buffer cache"（buffer，cache的功能兼备）
一般情况下，Read,write系统调用并不直接访问磁盘。这两个系统调用仅仅是在用户空间和内核空间的buffer之间传递目标数据。举个例子，下面的write系统调用仅仅是把3个字节从用户空间拷贝到内核空间的buffer之后就直接返回了
write(fd,”abc”,3);
在以后的某个时间点上，内核把装着“abc”三个字节的buffer写入（flush）磁盘……
如果另外的进程在这个过程中想要读刚才被打开写的那个文件怎么办？答案是：内核会从刚才的buffer提供要读取的数据，而不是从磁盘读。
介绍完“写出”，该介绍“读入”了。
当前系统上第一次读一个文件时，Read系统调用触发内核以block为单位从磁盘读取文件数据，并把数据blocks存入内核buffer，然后read不断地从这个buffer取需要的数据，直到buffer中的数据全部被读完，接下来，内核从磁盘按顺序把当前文件后面的blocks再读入内核buffer，然后read重复之前的动作…
一般的文件访问，都是这种不断的顺序读取的行为，为了加速应用程序读磁盘，unix的设计者们为这种普遍的顺序读取行为，设计了这样的机制----预读，来保证进程在想读后续数据的时候，这些后续数据已经的由内核预先从磁盘读好并且放在buffer里了。这么做的原因是磁盘的io访问比内存的io访问要慢很多，指数级的差别。
read，write从语义和概念上来说，本来是必须要直接和磁盘交互的，调用时间非常长，应用每次在使用这两个系统的时候，从表象上来说都是被卡住。而有了这些buffer，这些系统调用就直接和buffer交互就可以了，大幅的加速了应用执行。
Linux内核并没有规定"buffer cache"的尺寸上线，原则上来说，除了系统正常运行所必需和用户进程自身所必需的之外的内存都可以被"buffer cache"使用。而系统和用户进程需要申请更多的内存的时候，"buffer cache"的内存释放行为会被触发，一些长久未被读取，以及被写过的脏页就会被释放和写入磁盘，腾出内存，以便被需要的行为方使用。
现在大体上你们已经知道了吧，"buffer cache"有五个flush的触发点：
1.pdflush(内核线程)定期flush；
2.系统和其他进程需要内存的时候触发它flush；
3.用户手工sync，外部命令触发它flush；
4.proc内核接口触发flush，"echo 3 >/proc/sys/vm/drop_caches；
5.应用程序内部控制flush。
这个"buffer cache"从概念上的理解就是这些了，实际上，更准确的说，linux从2.4开始就不再维护独立的"buffer cache"模块了，而是把它的功能并入了"page cache"这个内存管理的子系统了，"buffer cache"现在已经是一个unix系统族的普遍的历史概念了。
高性能写文件
写100MB的数据
场景1，1次写1个字节，总共write 100M次；
场景2，1次写1K个字节，总共write 100K次；
场景3，1次写4K个字节，总共write 25K次；
场景4，1次写16k个字节，总共write大约不到7K次。
以上4种写入方式，内核写磁盘的次数基本相同，因为写磁盘的单位是block，而不是字节。现在的系统默认的block都是4k。
第1种性能非常差，user time和system time执行时间都很长，既然写盘次数都差不多，那他慢在哪儿呢？答案是系统调用的次数太多
第2种，user time和system time都显著降低，不过system time降低幅度更大
第2种以后，性能差别就不是很高了，第3种和第4种性能几乎一样
有兴趣的朋友可以试一试，如果你的服务器很好，可以适当放大测试样本。
总而言之，得出的结论是以block的尺寸为write（fd, sizeof(buf),buf）的调用单位就可以了，再大对性能也没什么太大的提高。
题外话：一个衡量涉及IO程序的好坏的粗略标准是“程序运行应该尽量集中在user time，避免大量的system time”以及“IO的时候肯定是需要一些应用层buf的，比如上述4个场景，匹配就可以了（比如场景3，场景1和场景2会导致系统调用次数太多，场景4使用的buf尺寸过于浪费）”
每个系统调用在返回的时候，会有一个从内核态向用户态切换的间隙，每次在这个间隙里面，系统要干两个事情----递送信号和进程调度，其中进程调度会重新计算全部RUN状态进程的优先级。
系统调用太多的话，递送信号和进程调度引起的计算量是不容忽视的。
精确地flush "buffer cache"
在很多业务场景下，我们仅仅调用write()把需要写盘的数据推送至内核的"buffer cache"中，这是很不负责任的。或许我们应该不断地频繁地把"buffer cache"中的数据强制flush到磁盘，尽最大可能保证我们的业务数据尽量不因断电而丢失。
天下没有免费的午餐，既想要效率(写入内核buffer)，又想要安全性(数据必须flush到外存介质中才安全)，这似乎是很矛盾的。SUSv3(Single UNIX Specification Version 3)给了这种需求一个折中的解决方案，让OS尽量满足我们的苛刻的要求。介绍这个折中方案之前，有两个SUSv3提案的规范很重要，说明如下：
1.数据完整性同步(synchronized I/O data integrity)
一个常规文件所包含的信息有两种：文件元数据和文件内容数据。
文件元数据包括：文件所属用户、组、访问权限，文件尺寸，文件硬连接数目，最后访问时间戳，最后修改时间戳，最后文件元数据修改时间戳，文件数据块指针。
对于文件内容数据，大家应该都很清楚是什么东西。
对于写操作，这个规范规定了，写文件时保证文件内容数据和必要的文件元数据保持完整性即可。粗糙地举个例子来解释这个规范，某次flush内核中的数据到磁盘的时候，仅仅把文件内容数据写入磁盘即可，但是如果这次写文件导致了文件尺寸的变化，那么这个文件尺寸作为文件的元数据也需要被写入磁盘，必要信息保持同步。而其他的文件元数据，例如修改时间，访问时间一概略去，不需要同步。
2.文件完整性同步(synchronized I/O file integrity)
相对于数据完整性同步而言，这个规范规定了，所有内容数据以及元数据都要同步。
下面来介绍linux提供的几种flush内核缓冲数据的几种方案，相信看完之后，大家应该知道上述提及的折中方案是怎样的:)
1.
int fsync(int fd);
文件完整性同步；
2.
int fdatasync(int fd);
数据完整性同步。
fdatasync相对于fsync的意义在于，fdatasync大致仅需要一次磁盘操作，而fsync需要两次磁盘操作。举例说明一下，假如文件内容改变了，但是文件尺寸并没有发生变化，那调用fdatasync仅仅是把文件内容数据flush到磁盘，而fsync不仅仅把文件内容flush刷入磁盘，还要把文件的last modified time也同步到磁盘文件系统。last modified time属于文件的元数据，一般情况下文件的元数据和文件内容数据在磁盘上不是连续存放的，写完内容数据再写元数据，必然涉及到磁盘的seek，而seek又是机械硬盘速度慢的根源。。。
在某些业务场景下，fdatasync和fsync的这点微小差别会导致应用程序性能的大幅差异。
3.
sync_file_range()
这个接口是linux从2.6.17之后实现的，是linux独有的非标准接口。这个接口提供了比fdatasync更为精准的flush数据的能力。详细请参照man。
4.
void sync(void);
强制"buffer cache"中的数据全部flush到磁盘，并且要遵循文件完整性同步。
上面4种方式介绍完毕，open()系统调用的打开文件的标志位，比如O_DSYNC诸如此类的标志，对flush数据的影响和上面几个接口作用类似。
预读
上面介绍了写buffer以及如何控制buffer的flush，下面来讲一讲如何控制读cache的行为。
读cache这一块，基本上，我们可以控制的就是文件的预读。
我们从POSIX规定的一个接口来论述一下如何控制文件的预读以及控制它的意义。接口原型如下：
#include
int posix_fadvise(int fd, off_t offset, off_t len, int advice);
fd：打开文件的描述符其实；
offset和len：指明文件区域；
advice：预读的方式。预读方式及其意义如下：
1. POSIX_FADV_NORMAL：内核默认的预读方式；
2. POSIX_FADV_RANDOM：内核禁用预读。适合随机读文件的业务，每次按业务要求的量读取数据，不多读；
3. POSIX_FADV_SEQUENTIALP：内核把默认的预读量(POSIX_FADV_NORMAL)扩大一倍；
4. POSIX_FADV_WILLNEED：读取出来的内容会被应用程序多次访问(就是应用程序会不断的调用read()对这些内容不断的读)；
5. POSIX_FADV_NOREUSE：读取出来的内容只会被应用程序访问一次，访问一次之后就清理掉并且释放内存。cache服务器，比如memcache或者redis启动时，把文件内容加载到应用层cache，就是这个参数存在的典型场景；
6. POSIX_FADV_DONTNEED：应用程序后续不打算访问指定范围中的文件内容，内核从"page cache(buffer cache)"中删除指定范围的文件内容，释放内存。
对于POSIX_FADV_WILLNEED这种方式，linux自己有一个特定接口，原型如下：
ssize_t readahead(int fd, off64_t offset, size_t count);
linux的"buffer cache"默认预读128k。
实际上，OS全局控制"buffer cache"的操作接口不仅仅是上面提及的几种，/proc/sys/vm/目录下还有几个参数可以从其他一些方面来控制"buffer cache"的行为，这部分内容在之后我整理笔记之后会介绍。
IO之标准C库buffer
在论述这个主题之前，先介绍一下标准C库和linux系统调用以及windows API之间的关系。
拿写文件来举个例子
linux下写文件用write()
windows下写文件用WriteFile()
这说明不同操作系统实现同样的系统功能的接口应该是不一样的。造成这种现状是操作系统发展的历史原因造成的，无法在操作系统的层面统一系统函数接口。同样功能的程序在linux上写一套，windows上又得写另外一套，毫无移植性可言。如果要开发一个既能在linux跑，又能在windows上跑的程序，开发成本飙升！
为了解决这个移植性的问题，标准C库利用了封装技术，扮演了一个重要的角色，统一了部分基本功能接口。
标准C规定的写文件的函数是fwrite()，就是不管在linux还是在windows上，各自都有一个标准C库，库函数封装的下层细节不一样，但是接口完全一样，提供的功能完全一样。
这是怎么做到的？猜一猜大致实现就知道了
在linux上，标准C接口fwrite()的实现伪代码
size_t fwrite(const void* buffer, size_t size, size_t count, FILE* stream){
...
...
return write(stream->fd,buffer,count);
}
在windows上，标准C接口fwrite()的实现伪代码
size_t fwrite(const void* buffer, size_t size, size_t count, FILE* stream){
#define OUT
BOOL ret = false；
OUT int optnum;
...
...
ret = WriteFile(stream->filehandle, buffer, count, &optnum,...);
if( ret == true)
return optnum;
else
return -1;
}
内部实现不一致，没关系，接口一样就可以，不管在linux还是windows上，写文件都用fwrite()，分别在各自平台上编译就可以了。
标准C就是这样一个处于系统层面之上的应用层标准函数库，为了统一各个操作系统上的函数接口而生。
回到我们的主题----IO之应用层buffer
什么是应用层buffer？
回想一下我之前介绍的《IO之内核buffer"buffer cache"》，既然write()能把需要写文件的数据推送到一个内核buffer来偷工减料欺骗应用层（为了加速I/O），说“我已经写完文件并返回了”。那应用层的标准C库的fwrite()按道理也可以为了加速，在真正调用write()之前，把数据放到(FILE*)stream->buffer中，等到多次调用fwrite()，直至(FILE*)stream->buffer中积攒的数据量达到(FILE*)stream->bufferlen这么多的时候，一次性的把这些数据全部送入write()接口，写入内核，这是多么美妙啊。。。
实际上，标准C库就是这么做的！
把fwrite()的linux实现再细致一下
过程其实仍然很粗糙，为了突出buffer的重点，计算stream->buffer是否满，拷贝多少，填充多少这样的细节和主题无关的东西我略去了
size_t fwrite(const void* buffer, size_t size, size_t count, FILE* stream){
...
if( stream->buffer满 ){
write(stream->fd,stream->buffer,stream->bufferlen);
} else{
拷贝buffer内容至stream->buffer
}
...
return count;
//过程很粗糙，为了突出buffer的重点，计算stream->buffer是否满，拷贝多少，填充多少这样的细节和主题无关的东西我略去了
}
fwrite()在windows平台的实现也基本上是这样的，也有buffer。
值得一说的是，fread()也有一个读cache来完成预读。
setvbuf()和setbuf()都是控制这个标准C库的buffer的。
还有fflush()是C库用于flush数据的函数。
以上三个函数，如果大家有兴趣，可以去看看linux上对应的man文档。
重点是要知道不仅系统的内核有buffer，应用层的C库同样也有buffer。这些buffer的唯一作用就是为了加速应用，不让应用老是卡在和磁盘交互上。
说个题外话，实际上对于磁盘、RAID卡、盘阵这样的外存介质而言，他们各自在硬件上也都有一层前端的buffer，有时也叫cache，用来缓冲读写加速。cache越多，价格越贵，性能越好。大型存储设备一般拥有多层cache，用的是昂贵的SSD。
需要分享的一点经验是，不管是标准C库的buffer也好，内核的"buffer cache"也罢，我们终究对它们的控制力度是有限的。我们在做服务器程序的时候，如果业务上涉及太大的I/O量，需要做服务整体加速的时候，我们一般自己在业务层做一层自己的"buffer"，把业务数据buffer住，攒成以文件系统或者磁盘的block块单位的大块数据，然后集中写，然后集中写又有集中写的策略。。。
再引申一点内容，做高性能大流量的大站的架构，其中最重要几个架构角色之一就是cache。前端CDN、后端memcache、redis、mysql内部cache等等，都是cache的应用场景，可以说"buffer cache"在服务器领域从软件实现到硬件加速再到架构，真的是无处不在。
IO队列和IO调度
IO体系概览
先看看本文主题IO调度和IO队列处于整个IO体系的哪个位置，这个IO体系是非常重要的，了解IO体系我们可以对整个IO过程有个全面的认识。虽然一下两下并不清楚IO体系各个部分的细节，但是我们总是能从这儿找到脉络。知道什么问题在什么位置，这个是解决问题的时候最关键的。任何所谓的专家都不太可能100%的了解全部细节，但是知道脉络，可以针对问题有的放矢。
实际上也不用完全明白，没有必要:):)
接下来咱们还是继续主题，请看下图
(注意：本图不涉及direct I/O)
图中数据流箭头1,2如果不了解请参照拙文《IO之标准C库buffer》。
图中数据流箭头3如果不了解请参照拙文《IO之内核buffer----"buffer cache"》。
IO调度和IO队列
1.向块设备写入数据块或是从块设备读出数据块时,IO请求要先进入IO队列，等待调度。
2.这个IO队列和调度的目标是针对某个块设备而言的，换句话说就是每个块设备都有一个独立的IO队列。
3.本篇所涉及的所谓的块设备就是iostat命令里面列出的形如sda,sdb这样的块设备，并不是指物理磁盘。假如一个盘被分成5个分区，那么在这个主题下，5个分区代表5个块设备，每个块设备都有自己独立的IO队列。
4.I/O 调度程序维护这些队列,以便更有效地利用外存设备。简单来说，IO调度程序将无序的IO操作变为大致有序的IO请求。比如调度的时候调整几个IO请求的顺序，合并那些写盘区域相邻的请求，或者按照写磁盘的位置排序这些请求，以降低磁头在磁盘上来回seek的操作，继而加速IO。
5.每个队列的每一次调度都会把整个队列过一遍，类似于进程调度的时候每次调度都要计算RUN队列的全部进程的优先级。
IO队列深度
这个参数是iostat里面呈现的，字面意思显而易见，就是IO队列的深度，这个参数有何意义呢？
针对每个机械物理盘，如果这个盘对应的IO队列深度超过3，那么基本上表示这个盘处理IO硬件请求有点吃紧，这个盘对应的IO队列深度怎么算呢？
还拿上面一个盘被切成5个分区说事儿，5个分区对应5个块设备，5个块设备对应5个IO队列，这5个IO队列的深度总和就是这个机械物理盘的IO队列深度了。
如何解决这个盘的IO请求吃紧呢，最简单的办法硬件加速，把这个盘换成SSD盘:)
说到这儿，我想提一提RAID卡。咱们使用RAID卡把几个硬盘放在一起，让系统只能看见一个块设备。这个时候，假如有4个盘被放在RAID后面。那么这个RAID卡对应的块设备的IO队列深度允许超过12(4个磁盘，每个盘承受深度为3)。
SSD盘可承受的IO队列深度值很大，这个多少深度合适，我没有注意具体观察过。
iostat另一个参数----"%util"
实际生产系统上，我观察IO设备是否吃紧，其实是看这个util的。这个值长期高于60，咱们就得考虑物理磁盘IO吃不消了。
如果是使用机械硬盘的服务器上这个值达到90以上，最简单的解决方案仍然是换SSD盘，换完之后这个值会下降到20左右，非常有效。
IO调度算法
IO调度算法存在的意义有两个：一是提高IO吞吐量，二是降低IO响应时间。然而IO吞吐量和IO响应时间往往是矛盾的，为了尽量平衡这两者，IO调度器提供了多种调度算法来适应不同的IO请求场景。
以下几个算法介绍是网上抄来的，说的很详细，作者水平很高:)
1、NOOP
该算法实现了最简单的FIFO队列，所有IO请求大致按照先来后到的顺序进行操作。之所以说"大致"，原因是NOOP在FIFO的基础上还做了相邻IO请求的合并，并不是完完全全按照先进先出的规则满足IO请求。
假设有如下的io请求序列：
100，500，101，10，56，1000
NOOP将会按照如下顺序满足：
100(101)，500，10，56，1000
2、CFQ
CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序，而不是按照先来后到的顺序来进行响应。
假设有如下的io请求序列：
100，500，101，10，56，1000
CFQ将会按照如下顺序满足：
100，101，500，1000，10，56
在传统的SAS盘上，磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序，以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是，先来的IO请求并不一定能被满足，可能会出现饿死的情况。
3、DEADLINE
DEADLINE在CFQ的基础上，解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外，DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms，写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高，而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下：
FIFO(Read) > FIFO(Write) > CFQ
这个算法特别适合数据库这种随机读写的场景。
4、ANTICIPATORY
CFQ和DEADLINE考虑的焦点在于满足离散IO请求上。对于连续的IO请求，比如顺序读，并没有做优化。为了满足随机IO和顺序IO混合的场景，Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上，为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求，就可以立即满足。
IO调度器算法的选择，既取决于硬件特征，也取决于应用场景。
在传统的SAS盘上，CFQ、DEADLINE、ANTICIPATORY都是不错的选择；对于专属的数据库服务器，DEADLINE的吞吐量和响应时间都表现良好。然而在新兴的固态硬盘比如SSD、Fusion IO上，最简单的NOOP反而可能是最好的算法，因为其他三个算法的优化是基于缩短寻道时间的，而固态硬盘没有所谓的寻道时间且IO响应时间非常短。
IO调度算法的查看和设置
查看和修改IO调度器的算法非常简单。假设我们要对sda进行操作，如下所示：
cat /sys/block/sda/queue/scheduler
echo 'cfq' >/sys/block/sda/queue/scheduler
还有持久化设置，不一一列举了。
调整IO优先级----ionice
这个我本人没用过，但是看起来很诱人:)
IO性能测试
工具有fio，iometre和简单实用的dd
如何系统化的测试和观察RAID卡，SSD，SAS这样的存储介质。后续我会在专门的硬件加速方面介绍。