如何提高Linux服务器磁盘io性能

您好，很高兴为您解答。

在现有文件系统下进行优化：

linux内核和各个文件系统采用了几个优化方案来提升磁盘访问速度。但这些优化方案需要在我们的服务器设计中进行配合才能得到充分发挥。

文件系统缓存

linux内核会将大部分空闲内存交给虚拟文件系统，来作为文件缓存，叫做page cache。在内存不足时，这部分内存会采用lru算法进行淘汰。通过free命令查看内存，显示为cached的部分就是文件缓存了。

如何针对性优化：

lru并不是一个优秀淘汰算法，lru最大的优势是普适性好，在各种使用场景下都能起到一定的效果。如果能找到当前使用场景下，文件被访问的统计特征，针 对性的写一个淘汰算法，可以大幅提升文件缓存的命中率。对于http正向代理来说，一个好的淘汰算法可以用1GB内存达到lru算法100GB内存的缓存 效果。如果不打算写一个新的淘汰算法，一般不需要在应用层再搭一个文件cache程序来做缓存。

最小分配：

当文件扩大，需要分配磁盘空间时，大部分文件系统不会仅仅只分配当前需要的磁盘空间，而是会多分配一些磁盘空间。这样下次文件扩大时就可以使用已经分配好的空间，而不会频繁的去分配新空间。

例如ext3下，每次分配磁盘空间时，最小是分配8KB。

最小分配的副作用是会浪费一些磁盘空间（分配了但是又没有使用）

如何针对性优化：

我们在reiserfs下将最小分配空间从8KB改大到128K后提升了30%的磁盘io性能。如果当前使用场景下小文件很多，把预分配改大就会浪费很多 磁盘空间，所以这个数值要根据当前使用场景来设定。似乎要直接改源代码才能生效，不太记得了，09年的时候改的，有兴趣的同学自己google吧。

io访问调度：

在同时有多个io访问时，linux内核可以对这些io访问按LBA进行合并和排序，这样磁头在移动时，可以“顺便”读出移动过程中的数据。

SATA等磁盘甚至在磁盘中内置了io排序来进一步提升性能，一般需要在主板中进行配置才能启动磁盘内置io排序。linux的io排序是根据LBA进行的，但LBA是一个一维线性地址，无法完全反应出二维的圆形磁盘，所以磁盘的内置io排序能达到更好的效果。

如何针对性优化：

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

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

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

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

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

小提示：

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

预读取：

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

如何针对性优化：

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

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

延迟分配：

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

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

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

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

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

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

如何针对性优化：

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

在线磁盘碎片整理：

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

1、让每个文件连续存储

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

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

如何针对性优化：

“让每个目录下的文件连续存储”是一个极有价值的功能。

传统的做法是通过拼接图片来将这10张图片合并到一张大图中，再由前端将大图切成10张小图。

有了e4defrag后，可以将需连续访问的文件放在同一个文件夹下，再定期使用e4defrag进行磁盘整理。

实现自己的文件系统：

在大部分服务器上，不需要支持“修改文件”这个功能。一旦文件创建好，就不能再做修改操作，只支持读取和删除。在这个前提下，我们可以消灭所有文件碎片，把磁盘io效率提升到理论极限。

有一个公式可以衡量磁盘io的效率：

磁盘利用率 = 传输时间/（平均寻道时间+传输时间）

如若满意，请点击回答右侧【采纳答案】，如若还有问题，请点击【追问】

~ O(∩_∩)O~

IO实际上是计算机用语，也写作I/O，指输入/输出(Input/Output)。硬盘IO就是指对字节的读取速度，即硬盘的读写能力。

扩展资料

I/O输入/输出(Input/Output)，分为IO设备和IO接口两个部分。在POSIX兼容的`系统上，例如Linux系统，I/O操作可以有多种方式，比如DIO(DirectI/O)，AIO(AsynchronousI/O，异步I/O)，Memory-MappedI/O(内存映射I/O)等，不同的I/O方式有不同的实现方式和性能，在不同的应用中可以按情况选择不同的I/O方式。

    具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

   为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

    相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert操作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢? 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？

 当数据库出现响应时间不稳定的时候，我们在操作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO. 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么操作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问. 数据页不在buffer bool 里面该怎么办？

  回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 图片中显示

buffer_read_page函数栈的顶层是pread64(),调用了操作系统的读函数。

buf_read_page的代码

 如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的操作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待操作系统完成IO .

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？   代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到操作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写操作是不堵塞执行sql的会话线程的。所以，即使看到操作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在操作系统上基本看不到读的IO。  当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

---