选择Linux I/O调度程序

我读到,通过写入/ sys/block/[disk]/queue/scheduler,可以在运行的内核上更改特定设备的I/O调度程序.例如,我可以在我的系统上看到:

anon@anon:~$ cat /sys/block/sda/queue/scheduler 
noop anticipatory deadline [cfq] 

默认是完全公平的排队调度程序.我想知道的是,在我的自定义内核中包含所有四个调度程序是否有任何用处.除非内核足够智能为正确的硬件选择正确的调度程序,特别是基于闪存的驱动器的"noop"调度程序和传统的其他调度程序之一,似乎编译多个调度程序没有多大意义.硬盘.

是这样的吗？

1> ephemient..：

---

如上所述/usr/src/linux/Documentation/block/switching-sched.txt,任何特定块设备上的I/O调度程序都可以在运行时更改.可能存在一些延迟,因为之前的调度程序的请求在使用新调度程序之前都已刷新,但即使设备使用频繁,也可以毫无问题地进行更改.

# cat /sys/block/hda/queue/scheduler
noop deadline [cfq]
# echo anticipatory > /sys/block/hda/queue/scheduler
# cat /sys/block/hda/queue/scheduler
noop [deadline] cfq

理想情况下,会有一个调度程序来满足所有需求.它似乎还不存在.内核通常没有足够的知识为您的工作负载选择最佳的调度程序:

noop 通常是内存支持的块设备(例如ramdisks)和其他非旋转介质(闪存)的最佳选择,其中尝试重新安排I/O是浪费资源

deadline 是一个轻量级的调度程序,试图对延迟进行严格的限制

cfq 试图保持系统范围的I/O带宽公平性

默认是anticipatory很长一段时间,它收到了很多调整,但在2.6.33(2010年初)被删除. cfq在一段时间之前成为默认,因为它的性能是合理的,公平性是多用户系统(甚至是单用户桌面)的一个很好的目标.对于某些情况 - 数据库通常用作示例,因为它们往往具有自己特有的调度和访问模式,并且通常是最重要的服务(所以谁关心公平？) - anticipatory具有可调整的悠久历史为了在这些工作负载上获得最佳性能,deadline并将所有请求快速传递到底层设备.

---

您可以添加udev规则以根据设备特征定义调度程序,如debian wiki(https://wiki.debian.org/SSDOptimization#Low-Latency_IO-Scheduler)#set for deadline scheduler for non-rotating disks ACTION == "add | change",KERNEL =="sd [az]",ATTR {queue/rotational} =="0",ATTR {queue/scheduler} ="deadline"

---

您可以将内核配置为默认使用不同的调度程序.在非旋转媒体上自动使用"noop"会很聪明,但内核没有这种功能.它确实检测到非旋转介质,但它不可靠,因为有些磁盘误报了自己,并且它还没有连接到I/O调度程序代码.

2> Dani_l..：

---

可以使用udev规则让系统根据hw的某些特性决定调度程序.
SSD和其他非旋转驱动器的示例udev规则可能如下所示

# set noop scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="noop"

在新的udev规则文件中(例如,/etc/udev/rules.d/60-ssd-scheduler.rules).这个答案基于debian wiki

要检查ssd磁盘是否使用该规则,可以提前检查触发器属性:

for f in /sys/block/sd?/queue/rotational; do printf "$f "; cat $f; done

3> MarkR..：

---

让内核支持不同内核的目的是你可以在不重启的情况下试用它们; 然后,您可以通过sytsem运行测试工作负载,测量性能,然后将其作为应用程序的标准工作负载.

在现代服务器级硬件上,只有noop硬件才有用.其他人在我的测试中看起来比较慢.