☰

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

tag-icon • tag-icon linux storage performance-tuning scheduler ionice
如何测试 ionice 的效果（针对使用 cfq 调度程序的设备）？

我正在尝试构建一个实验来测量 ionice 的效果。我想要做的是（根据serverfault 上的另一个答案) 会导致足够频繁的 I/O，以至于足够“niced”的进程无法获得任何 I/O。

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

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

然后我使用ionice -c3（闲置的调度类）针对公共设备上的一个文件。我同时使用默认的（最大努力)调度类，指定公共设备上的不同文件（改变延迟值）。

我的假设是，对于“尽力而为”进程的延迟值为 250 毫秒或更大，我会看到“空闲”进程所取得的进展；对于小于 250 毫秒的值，我将看不到“空闲”进程所取得的进展。

我的观察是，这两个进程的性能没有差异；它们都取得了类似的进展。为了确保万无一失（以防挂钟指示“尽力而为”进程执行 I/O 的速度远快于每 250 毫秒），我启动了“尽力而为”进程的多个同时实例，指定无（零）延迟。不过，我发现两个调度类中的进程在性能上没有差异。

为了确保万无一失，我重新检查了调度程序类：

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

我对 cfq 调度程序的工作原理有什么误解？

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

答案1

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

至于 cfq，RHEL5 生命周期（2.6.18 版）似乎有所变化。在我的应用服务器上，这种变化非常明显，以至于我不得不因为争用问题而改用noop和电梯。deadline

相关内容