linux - ionice 'idle' 没有达到预期的效果

Question

我们正在使用一个相当繁忙的网络服务器。我们想使用 rsync 进行一些数据移动，这显然会破坏磁盘，因此我们使用 ionice 将 rsync 进程置于空闲类中。系统 (SSD+HDD) 上两个磁盘的队列都设置为使用 CFQ 调度程序。结果……磁盘彻底被砸烂，网站性能惨不忍睹。

我已经做了一些挖掘，看看是否有任何调整可以帮助解决这个问题。ionice 的手册页说:

Idle: A program running with idle I/O priority will only get disk time
when no other program has asked for disk I/O for a defined grace period.
The impact of an idle I/O process on normal system activity should be zero.

我在 Google 的帮助下找到的任何地方都没有清楚地解释这个“定义的宽限期”。一篇帖子表明它是 fifo_expire_async 的值，但我找不到任何对此的真正支持。

但是，在我们的系统上，fifo_expire_async 和 fifo_expire_sync 都设置得足够长(250 毫秒、125 毫秒，这是默认值)，空闲类实际上应该没有磁盘带宽。即使认为宽限期由 fifo_expire_async 设置的人完全错误，在“空闲 I/O 进程对正常系统事件的影响”的陈述中也没有太多回旋余地应该为零”。

显然这不是我们机器上发生的事情，所以我想知道 CFQ+idle 是否只是被破坏了。

有没有人设法让它工作？非常感谢提示!

更新:我今天做了更多的测试。我写了一个小的 Python 应用程序来读取整个磁盘的随机扇区，中间有短暂的休眠。我在没有 ionice 的情况下运行了这个副本，并将其设置为每秒执行大约 30 次读取。然后，我使用各种 ionice 类运行了该应用程序的第二个副本，以查看空闲类是否按照盒子上的说明进行操作。当我使用 1、2、3 类(实时、尽力而为、空闲)时，我发现结果之间完全没有区别。这个，尽管我现在绝对确定磁盘很忙。 因此，我现在可以肯定 - 至少对于我们的设置 - CFQ+idle 不起作用。 [请参阅下面的更新 2 - 与其说“不起作用”不如说“不起作用”预期“...]

仍然非常欢迎评论!

更新 2:更多戳今天。发现当我大幅提高 I/O 速率时，空闲级进程实际上开始变得饥饿。在我的测试中，这发生在 I/O 速率大大高于我预期的情况下——基本上是每秒数百个 I/O。我仍在尝试弄清楚调整参数的作用...

我还发现了一个相当重要的事实，即异步磁盘写入根本不包含在 I/O 优先级系统中!我在上面引用的 ionice 联机帮助页没有提及该事实，但系统调用 ioprio_set() 的联机帮助页指出:

I/O priorities are supported for reads and for synchronous (O_DIRECT, O_SYNC) writes. I/O priorities are not supported for asynchronous writes because they are issued outside the context of the program dirtying the memory, and thus program-specific priorities do not apply.

这极大地改变了我处理性能问题的方式，我将提议对 ionice 联机帮助页进行更新。

关于内核和 iosched 设置的更多信息(sdb 是 HDD):

Linux 4.9.0-4-amd64 #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) x86_64 GNU/Linux
/etc/debian_version = 9.3

(cd /sys/block/sdb/queue/iosched; grep . *)
back_seek_max:16384
back_seek_penalty:2
fifo_expire_async:250
fifo_expire_sync:125
group_idle:8
group_idle_us:8000
low_latency:1
quantum:8
slice_async:40
slice_async_rq:2
slice_async_us:40000
slice_idle:8
slice_idle_us:8000
slice_sync:100
slice_sync_us:100000
target_latency:300
target_latency_us:300000

Answer 1

据我所知，解决您的问题的唯一机会是使用 CGroup v2(内核 v. 4.5 或更新版本)。请参阅以下文章:

https://andrestc.com/post/cgroups-io/

另请注意，您可以使用 systemd 的包装器在每个服务的基础上配置 CGroup 限制:

http://0pointer.de/blog/projects/resources.html