スキップしてメイン コンテンツに移動

I/OスケジューラでSSDのパフォーマンスは変わるのか?

以前、Unbreakable Enterprise KernelのI/O schedulerがdeadlineに変更されたとブログに書きました。
また、SSDであればnoopの方が合っているかもしれないとコメントに書きました。

実際のところ、どうなのでしょうか? 検証してみます。

まずは、I/O schedulerを変更してみます。変更するには3通りあるのですが、

1. bootパラメータ(elevator)を変更する
2. /sys/block/<device>/queue/schedulerを直接変更する
3. udevのルールを変更する

今回は、検証なので、2の直接書き換え方式を使っていますが、通常はは、SSDのみをnoopとしたい、かつ、リブートで元に戻って欲しくない等になるので、3のudevルールで対応すると思います。

以下のudevのルールを/etc/udev/rule.dに作成します。

SUBSYSTEM=="block", SYSFS{queue/rotational}=="0", RUN+="/bin/sh -c 'echo noop > /sys$devpath/queue/scheduler'"

* queue/rotationalは磁気ディスクであれば1が設定され、SSDであれば0が設定されますが、USBのような安価なフラッシュ
  ディスクの場合は1が設定される場合があるようです


今回は、15セッションでTPC-Cのベンチマークを実施してみました。

1. deadline
$ su - root -c "echo deadline > /sys/block/sdc/queue/scheduler"
$ su - root -c "echo 3 > /proc/sys/vm/drop_caches"



Unbreakable Enterprise KernelではデフォルトとなっているdeadlineI/Oスケジューラのパフォーマンスをチェックしておきます。 今回のテストの結果では、平均のレスポンスタイムが22msとなっていました。

2. noop
$ su - root -c "echo noop > /sys/block/sdc/queue/scheduler"
$ su - root -c "echo 3 > /proc/sys/vm/drop_caches"



I/Oスケジューラを今回のテスト目的であるnoopに変更してのパフォーマンスをチェックしてみます。 今回のテストの結果では、平均のレスポンスタイムはdeadlineと同じ22msとなっていました。

3. cfq
$ su - root -c "echo cfq > /sys/block/sdc/queue/scheduler"
$ su - root -c "echo 3 > /proc/sys/vm/drop_caches"



更に、以前のカーネルでデフォルトであったcfqのパフォーマンスも一応見てみます。 平均のレスポンスタイムは23msとなり、他のI/Oスケジューラと遜色ないパフォーマンスでした。

ということ、今回のテストでは、I/Oスケジューラでのパフォーマンスにおける変化はみられませんでした。もう少し、I/Oが厳しい環境でテストすると状況が変わってくるかも知れませんが。。。

コメント