一 机械磁盘的io的速度主要受“寻道速度”的限制，所以在访问小文件时io性能会极差。如果不在乎成本，可以通过使用固态硬盘来解决这个问题。

如何针对性优化：

io访问调度能大幅提升io性能，前提是应用层同时发起了足够的io访问供linux去调度。

怎样才能从应用层同时向内核发起多个io访问呢?

方案一是用aio_read异步发起多个文件读写请求。

方案二是使用磁盘线程池同时发起多个文件读写请求。

对我们的http正向代理来说，采用16个线程读写磁盘可以将性能提升到2.5倍左右。具体开多少个线程/进程，可以根据具体使用场景来决定。

小提示：

将文件句柄设置为非阻塞时，进程还是会睡眠等待磁盘io，非阻塞对于文件读写是不生效的。在正常情况下，读文件只会引入十几毫秒睡眠，所以不太明显;而在磁盘io极大时，读文件会引起十秒以上的进程睡眠。

详见内核源代码do_generic_file_read会调用lock_page_killable进入睡眠，但是不会判断句柄的非阻塞标志。

预读取

linux内核可以预测我们“将来的读请求”并提前将数据读取出来。通过预读取可以减少读io的次数，并且减小读请求的延时。

如何针对性优化：

预读取的预测准确率是有限的，与其依赖预读取，不如我们直接开一个较大的缓冲区，一次性将文件读出来再慢慢处理;尽量不要开一个较小的缓冲区，循环读文件/处理文件。

究竟开多大缓冲区合适，要根据具体使用场景下的内存/磁盘io压力来决定。

虽然说“预读取”和“延迟分配”能起到类似的作用，但是我们自己扩大读写缓冲区效果要更好。

延迟分配

当文件扩大，需要分配磁盘空间时，可以不立即进行分配，而是暂存在内存中，将多次分配磁盘空间的请求聚合在一起后，再进行一次性分配。

延迟分配的目的也是减少分配次数，从而减少文件不连续。

延迟分配的副作用有几个：

1 如果应用程序每次写数据后都通过fsync等接口进行强制刷新，延迟分配将不起作用

2 延迟分配有可能间歇性引入一个较大的磁盘IO延时(因为要一次性向磁盘写入较多数据)

只有少数新文件系统支持这个特性

如何针对性优化：

如果不是对安全性(是否允许丢失)要求极高的数据，可以直接在应用程序里缓存起来，积累到一定大小再写入，效果比文件系统的延迟分配更好。

如果对安全性要求极高，建议经常用fsync强制刷新。

在线磁盘碎片整理

Ext4提供了一款碎片整理工具，叫e4defrag，主要包含三个功能：

1 让每个文件连续存储

2 尽量让每个目录下的文件连续存储

3 通过整理空闲磁盘空间，让接下来的分配更不容易产生碎片