磁盘读写优化

 先看一些参数

对读优化的参数
/sys/block/sda/queue/read_ahead_kb
这个参数对顺序读非常有用，意思是，一次提前读多少内容，无论实际需要多少。默认一次读 128kb 远小于要读的，设置大些对读大文件非常有用，可以有效的减少读 seek 的次数，这个参数可以使用 blockdev –setra 来设置，setra 设置的是多少个扇区，所以实际的字节是除以2，比如设置 512 ，实际是读 256 个字节。
几个非常有效的 IO 调度调节的内核参数
/proc/sys/vm/dirty_ratio
这个参数控制文件系统的文件系统写缓冲区的大小，单位是百分比，表示系统内存的百分比，表示当写缓冲使用到系统内存多少的时候，开始向磁盘写出数 据。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值，一般启动上缺省是 10。下面是增大的方法： echo ’40′> /proc/sys/vm/dirty_ratio

/proc/sys/vm/dirty_background_ratio
这个参数控制文件系统的pdflush进程，在何时刷新磁盘。单位是百分比，表示系统内存的百分比，意思是当写缓冲使用到系统内存多少的时候， pdflush开始向磁盘写出数据。增大之会使用更多系统内存用于磁盘写缓冲，也可以极大提高系统的写性能。但是，当你需要持续、恒定的写入场合时，应该降低其数值，一般启动上缺省是 5。下面是增大的方法： echo ’20′ > /proc/sys/vm/dirty_background_ratio

/proc/sys/vm/dirty_writeback_centisecs
这个参数控制内核的脏数据刷新进程pdflush的运行间隔。单位是 1/100 秒。缺省数值是500，也就是 5 秒。如果你的系统是持续地写入动作，那么实际上还是降低这个数值比较好，这样可以把尖峰的写操作削平成多次写操作。设置方法如下： echo ’200′ > /proc/sys/vm/dirty_writeback_centisecs 如果你的系统是短期地尖峰式的写操作，并且写入数据不大（几十M/次）且内存有比较多富裕，那么应该增大此数值： echo ’1000′ > /proc/sys/vm/dirty_writeback_centisecs

/proc/sys/vm/dirty_expire_centisecs
这个参数声明Linux内核写缓冲区里面的数据多“旧”了之后，pdflush进程就开始考虑写到磁盘中去。单位是 1/100秒。缺省是 30000，也就是 30 秒的数据就算旧了，将会刷新磁盘。对于特别重载的写操作来说，这个值适当缩小也是好的，但也不能缩小太多，因为缩小太多也会导致IO提高太快。建议设置为 1500，也就是15秒算旧。 echo ’1500′ > /proc/sys/vm/dirty_expire_centisecs 当然，如果你的系统内存比较大，并且写入模式是间歇式的，并且每次写入的数据不大（比如几十M），那么这个值还是大些的好。

小米运维一篇博客的部分内容
应用IO模型：大量读线程同时访问多块SSD，请求均为4KB随机读，并且被请求的数据有一定间隔连续性；

通过 /sys/block/sdx/queue/read_ahead_kb 观察到预读大小为128KB，进一步观察iostat情况：

观察到每块SSD的rMB/s十分高，平均已经达到了250MB/s+，初步判断是由于read_ahead_kb的设置影响了应用的读效率（即预先读取了过多不必要的数据）。遂将read_ahead_kb设置为0，观察iostat情况如下

而应用QPS却下降至25K！

分析原因：由于之前有预读功能存在，因此部分数据已经被预先读取而减轻了SSD的访问压力。将read_ahead_kb设置为0后，所有的读访问均通过随机读实现，一定程度上加重了SSD的访问压力（可以观察到之前%util大约在60~80%之间波动，而预读改成0之后%util则在80~90%之间波动）


尝试16K预读

通过IO模型了解到每次请求的数据大小为4KB，因此将read_ahead_kb设置为16KB进行尝试，结果QPS由25K猛增到34K！

观察iostat情况如下：

此时CPU_WA也由原来的平均30%下降到20%，这说明处理器等待IO的时间减少了，进一步验证了IO优化的有效性。

结论,频繁碎片读取的时候,预读大小设置小一点比较好
由于存在合并读取，设置太小也不适合
将预读大小设置为块大小的3～4倍数比较合适

由于上述场景是4k随机读取（因为分区格式化簇大小是4k？）,因此预读设置巍峨12～16比较适合

再看中断分配

于是我们通过mpstat观察每个核心上的中断数：

可以发现第二个核心中断数已经达到了十分恐怖的80K！再来观察实际的处理器核心压力情况，为了能够更加直观地了解，我们用了比较准确的i7z工具来观察：

果然不出所料，Core 1的Halt（idle）已经到了1，充分说明第二个核心确实已经满载。

那么通过观察/proc/interrupt的情况再来进一步验证我们的假设，：


因此我们将实际在处理中断的irq号107至118分别绑定至不同的核心上（这里就不再赘述有关多核绑定的原理，有兴趣的同学可以百度搜索以上命令的含义）：

通过观察mpstat发现大量的中断被平均分散到了不同的处理器核心上：

学习到
查看中断方法、工具
mpstat
/proc/interrupt
i7z

linux的中断分配并不那么智能（貌似只能优化主板上的通用部件？）,不能对应各种硬件
在硬件支持的情况下,手动绑定中断到不同cpu有很大改善空间
照这情况,高吞吐的网卡也需要自己绑定中断