如何测试 ionice 的效果（针对使用 cfq 调度程序的设备）？

Question

我正在尝试构建一个实验来测量 ionice 的效果。我想做的是（根据serverfault 的另一个答案）导致足够频繁的 I/O，以至于足够“好的”进程缺乏任何 I/O。

基于serverfault上的另一个答案，我认为我需要每 250 毫秒对一个常见的 cfq 调度设备进行至少一个实际 I/O 操作。我的想法是编写一个简单的程序，它确实有一个循环

• 写入公共设备上的（可配置）文件，
• 执行一个fsync()（强制执行确定的 I/O 操作），
• 用于usleep()延迟可配置的时间量
• 定期用于lseek()截断文件（这样我就不会填满文件系统）

然后我使用ionice -c3（空闲调度类）针对公共设备上的一个文件启动程序的一个实例。我同时使用默认（尽力而为）调度类运行各种实例，在公共设备上指定不同的文件（改变延迟值）。

我的假设是，对于“尽力而为”过程中 250 毫秒或更多的延迟值，我会看到“空闲”过程取得的进展；对于小于 250 毫秒的值，我认为“空闲”过程几乎没有进展。

我的观察是这两个过程的性能没有差异。他们都取得了类似的进展。只是为了确定（以防挂钟指示“尽力而为”进程执行 I/O 的速度比每 250 毫秒快得多），我启动了“尽力而为”进程的多个同时实例，指定 no（零）延迟。尽管如此，我仍然没有看到两个调度类中的进程之间的性能差异。

可以肯定的是，我重新检查了调度程序类：

$ cat /sys/block/xvda/queue/scheduler
noop anticipatory deadline [cfq] 

关于 cfq 调度程序的工作方式，我缺少什么？

如果重要的话，这是在 2.6.18 内核上。

Answer 1

我尝试使用负载生成器（如stress -i n或 ）来测量效果stress -d n，其中“n”是进程数。在一个窗口中运行它。尝试nmon或iostat在另一个中尝试同一块设备上的代表性应用程序进程。iostat查看服务时间如何随各种 ionice 设置（或在应用程序内测试响应）而变化。

至于 cfq，整个 RHEL5 生命周期（2018 年 6 月 2 日）似乎发生了变化。这在我的应用程序服务器上非常明显，由于争用问题，我不得不转移到电梯noop。deadline