调整IO调度算法可优化Linux磁盘性能，需根据设备类型（SSD/HDD/NVMe）、工作负载（数据库、桌面、虚拟化等）选择noop、deadline、BFQ或Kyber调度器，并通过sysfs临时修改或GRUB/udev永久配置，结合iostat、fio等工具测试验证效果。
在Linux系统里，调整IO调度算法是优化磁盘性能一个很直接且有效的方法，它能决定内核如何将来自不同进程的IO请求发送给存储设备。简单来说，就是告诉操作系统你的硬盘该怎么“排队”处理读写任务，这对系统的响应速度和吞吐量影响非常大，尤其是在特定的工作负载下。
解决方案
调整Linux中的IO调度算法，通常有几种做法，从临时生效到永久配置，总有一款适合你的场景。
最直接的方法是临时修改：
你可以通过
sysfs文件系统来查看和修改。比如，你想看看你的
sda盘当前用的是什么调度器，可以这样：
cat /sys/block/sda/queue/scheduler
输出会用方括号标出当前激活的调度器，比如
noop deadline [cfq]。
要临时切换，比如从
cfq换到
deadline：
echo deadline > /sys/block/sda/queue/scheduler
但这种修改在系统重启后就会失效。
如果想让修改永久生效，就需要编辑GRUB配置。这通常涉及到修改
/etc/default/grub文件，找到
GRUB_CMDLINE_LINUX_DEFAULT这一行，在其中添加或修改
elevator=参数。
例如，将其设置为
deadline：
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"
修改后，记得更新GRUB配置：
sudo update-grub # Debian/Ubuntu sudo grub2-mkconfig -o /boot/grub2/grub.cfg # CentOS/RHEL
然后重启系统才能生效。
对于某些特定的磁盘设备，你也可以通过udev规则来设置。这在你有多个不同类型磁盘，想对它们应用不同策略时特别有用。你可以在
/etc/udev/rules.d/目录下创建一个新的规则文件，比如
99-scheduler.rules：
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"这个例子是说，对于所有非旋转（固态硬盘）的sda设备，都将其调度器设置为
noop。创建或修改规则后，需要重载udev规则：
sudo udevadm control --reload-rules sudo udevadm trigger
常见的IO调度算法有哪些，它们各自适用于什么场景？
谈到Linux的IO调度器，我们主要会接触到几个名字：
noop、
deadline、
cfq、
BFQ，以及较新的
Kyber。它们各有侧重，理解它们的特性，是选择合适的关键。
noop（No Operation）：这是最简单的调度器，它不做任何IO请求的重新排序，直接将请求传递给下层设备。它的优势在于开销极低，几乎不引入任何延迟。所以，对于那些本身就能很好地处理并行IO的设备，比如SSD、NVMe固态硬盘，或者在虚拟化环境中，存储层的IO已经由宿主机或SAN设备处理了，
noop往往是最佳选择。它避免了不必要的调度开销，让设备自身去优化。
deadline：这个调度器引入了“截止时间”的概念。它会为每个读写请求设置一个过期时间，并优先处理那些即将过期的请求，同时尝试将读请求和写请求分开处理，以防止写操作长时间霸占磁盘而导致读请求饥饿。我的经验是，在很多数据库应用场景，或者混合读写负载的服务器上，
deadline表现相当均衡，能有效提升吞吐量和降低延迟。它在HDD和SSD上都有不错的表现。
cfq（Completely Fair Queuing）：顾名思义，它追求的是“完全公平”，为每个进程维护一个独立的IO队列，并尝试将磁盘带宽公平地分配给这些进程。它会尝试合并相邻的请求，并进行一些寻道优化。在桌面环境或通用服务器上，
cfq曾经是默认选项，因为它能提供较好的交互性体验，避免某个进程的IO操作完全卡住系统。但对于高并发、高吞吐量的场景，尤其是在SSD上，它的开销可能会比较大，因为它引入了更多的调度逻辑。在较新的内核版本中，
cfq的地位逐渐被
BFQ或
deadline取代，甚至在某些发行版中已不再是默认选项。
BFQ（Budget Fair Queuing）：这是
cfq的继任者，旨在提供更低的延迟和更好的公平性，特别是在交互式工作负载下。它通过“预算”的概念来管理IO，确保每个进程都能获得一定量的IO时间，从而提供更流畅的用户体验。如果你在用Linux桌面，或者需要保证多媒体应用、虚拟机等交互性应用的响应速度，
BFQ通常是个非常好的选择。它在HDD和SSD上都能表现出色，但在NVMe上可能不如
Kyber。
Kyber：这是一个相对较新的调度器，专门为NVMe等高性能、低延迟的固态存储设备设计。它基于多队列块层（blk-mq），能够更好地利用NVMe设备的并行处理能力，并通过控制延迟目标来优化性能。如果你使用的是最新的NVMe硬盘，并且系统内核版本支持，
Kyber通常能带来更好的性能表现，尤其是在高并发随机读写场景。
如何根据实际工作负载选择合适的IO调度器？
选择IO调度器，真的不是拍脑袋就能决定的事，它需要结合你的实际工作负载、存储设备类型以及系统内核版本来综合考量。我个人觉得，没有绝对的“最佳”选项，只有“最适合”你当前场景的。
1. 存储设备类型是首要考虑因素：
-
固态硬盘（SSD/NVMe）：这类设备没有机械臂寻道时间，内部并行处理能力很强。传统为机械硬盘设计的复杂调度算法（如
cfq
）反而会引入不必要的开销。因此，对于SSD或NVMe，我通常会推荐noop
或deadline
。noop
是最直接的，因为它几乎不做任何干预，让SSD控制器自己去优化IO。如果你的SSD需要处理大量并发请求，并且担心某些请求被“饿死”，deadline
也是个不错的选择，因为它有截止时间机制。而对于NVMe，如果你的内核支持，Kyber
是专门为它设计的，通常能发挥出更好的性能。 -
机械硬盘（HDD）：这类设备有物理寻道时间，IO请求的顺序对性能影响巨大。
deadline
和BFQ
是比较好的选择。deadline
能有效减少寻道，平衡读写吞吐量。BFQ
则更侧重于提供良好的交互性，适合桌面或需要保证多进程响应的服务器。
2. 工作负载特性决定调度策略：
-
数据库服务器/高IOPS应用：这类应用通常需要极低的延迟和高吞吐量，且IO模式往往是随机读写混合。
deadline
通常表现优秀，因为它能有效防止读写饥饿，并平衡吞吐量。如果使用NVMe，Kyber
的低延迟特性会很有优势。 -
虚拟化环境中的Guest OS：在虚拟机内部，IO请求最终还是会通过宿主机的调度器发送给物理存储。因此，在Guest OS里，使用
noop
通常是最佳实践。这避免了双重调度带来的额外开销和潜在冲突。宿主机上则根据其物理存储类型和负载选择合适的调度器。 -
桌面系统/交互式应用：用户体验至关重要，你希望系统能快速响应，不出现卡顿。
BFQ
是为这种场景量身定制的，它能确保应用程序的IO请求得到及时处理，提供更流畅的交互体验。 -
文件服务器/大数据处理：这类场景可能更侧重于高吞吐量，对延迟的敏感度相对低一些。
deadline
通常是个稳妥的选择，它能在保证吞吐量的同时，兼顾一定的公平性。
3. 别忘了测试和监控：
理论分析固然重要，但最终还是得看实际效果。在更改调度器后，务必使用
iostat、
iotop等工具来监控磁盘IO性能，比如IOPS、吞吐量、平均等待时间等指标。最好能在生产环境上线前，在测试环境中进行充分的基准测试。有时候，你会发现默认设置在你的特定场景下反而表现最好，或者改变调度器带来的提升微乎其微，因为瓶颈可能在CPU、内存或应用程序本身。
调整IO调度器时常见的误区或注意事项有哪些？
调整IO调度器，听起来像个“银弹”，但实际操作中，有很多细节和误区需要我们注意。它绝不是解决所有磁盘性能问题的万能药。
1. 并非性能瓶颈的唯一解： 这是最常见的误区。很多人一遇到磁盘慢，就想到调整IO调度器。但实际上，磁盘性能受多种因素影响：硬盘本身的物理性能（HDD vs SSD）、RAID配置、文件系统（ext4, xfs等）、应用程序的IO模式、CPU资源、内存大小、甚至操作系统内核版本和驱动程序。IO调度器只是其中一个环节。有时候，瓶颈可能在于文件系统参数不合理，或者应用程序的IO请求模式本身效率低下。
2. 内核版本的影响： 不同的Linux内核版本，IO调度器的实现可能会有所不同，甚至会引入新的调度器（比如
Kyber），或者废弃旧的（比如在某些新版内核中
cfq不再是默认甚至可能被移除）。所以，在参考网络上的优化建议时，一定要注意其对应的内核版本。你不能指望在CentOS 7（可能默认
cfq）上套用Ubuntu 20.04（可能默认
deadline或
BFQ）的优化经验。
3. 永久性配置的遗漏： 很多人在测试时通过
echo命令临时修改了调度器，发现性能提升了，就以为万事大吉。结果系统一重启，设置就恢复了默认。务必记住，生产环境的配置需要通过GRUB或udev规则来持久化。我见过不少因为忘记持久化配置，导致重启后性能又打回原形的案例。
4. 缺乏基准测试和监控： 盲目调整调度器，而不进行前后的性能对比，是毫无意义的。你必须有客观的数据来衡量调整的效果。使用
iostat -xd 1来观察磁盘的IOPS、吞吐量、平均队列长度、平均服务时间等指标。如果可能，使用
fio或
sysbench等工具进行压力测试，模拟真实负载。没有数据支撑的优化，都是“玄学”。
5. 云环境的特殊性： 在云计算环境中，你所操作的“磁盘”往往是虚拟化的，底层存储可能是SAN、NAS或者分布式存储系统。这种情况下，你Guest OS内部的IO调度器可能作用有限，因为真正的IO调度和优化发生在宿主机或存储设备层。在这些场景下，Guest OS内部通常推荐使用
noop，因为它开销最小，避免了不必要的重复调度。
6. 过度优化与“适可而止”： 有时候，默认的调度器在你的负载下已经足够优秀，或者你遇到的性能问题并非IO调度器能解决的。过度追求极致优化，可能会投入大量时间和精力，但实际收益甚微。在某些情况下，过于激进的调度器设置，反而可能在特定边缘负载下导致性能下降或不稳定性。保持一个务实的心态，先解决主要瓶颈，再考虑微调。
调整IO调度器是一项系统优化工作，它需要对Linux内核、存储设备和工作负载有一定理解。实践出真知，不断尝试、测试和监控，才能找到最适合你的配置。
