Linux I / Oスケジューラの選択

Question 1

/ sys / block / [disk] / queue / schedulerに書き込むことで、実行中のカーネル上の特定のデバイスのI / Oスケジューラーを変更できると思われることを読みました。たとえば、私のシステムで見ることができます：

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

デフォルトは完全に均等化キューイングスケジューラです。私が疑問に思っているのは、カスタムカーネルに4つのスケジューラーすべてを含めることに何か意味があるかどうかです。カーネルが正しいハードウェア用の正しいスケジューラー、特にフラッシュベースのドライブ用の「noop」スケジューラーと従来のドライブ用の他のスケジューラーを選択するのに十分賢くない限り、複数のスケジューラーをコンパイルすることにはあまり意味がないようです。ハードドライブ。

これは本当ですか？

Question 2

に記載/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 多くの場合、I / Oの再スケジュールを試みることがリソースの浪費である、メモリでバックアップされたブロックデバイス（ramdiskなど）やその他の非回転メディア（フラッシュ）に最適です。
deadline レイテンシーに厳しい制限を課そうとする軽量スケジューラーです
cfq I / O帯域幅のシステム全体の公平性を維持しようとします

デフォルトはanticipatory長い間で、多くの調整が行われましたが、2.6.33（2010年初頭）で削除されました。 cfqそのパフォーマンスは合理的であり、公平性はマルチユーザーシステム（およびシングルユーザーデスクトップでさえ）にとって良い目標であるため、しばらく前にデフォルトになりました。一部のシナリオ（データベースは、独自のスケジューリングとアクセスパターンをすでに持っている傾向があり、最も重要なサービスであることが多いため（公平性を気にする人はいますか？））、例としてよく使用されます。anticipatory調整可能であるという長い歴史があります。これらのワークロードで最高のパフォーマンスを実現し、deadlineすべての要求を基盤となるデバイスに非常に迅速に渡します。

Question 3

udevルールを使用して、ハードウェアのいくつかの特性に基づいてシステムにスケジューラーを決定させることができます。
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。この回答はDebianWikiに基づいています

SSDディスクがルールを使用するかどうかを確認するには、事前にトリガー属性を確認することができます。

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

Question 4

カーネルにさまざまなものをサポートさせる目的は、再起動せずにそれらを試すことができるようにすることです。次に、sytsemを介してテストワークロードを実行し、パフォーマンスを測定して、それをアプリの標準にすることができます。

最新のサーバーグレードのハードウェアでは、noopのものだけがまったく役立つように見えます。私のテストでは、他の人は遅いようです。

Question 5

「elevator」パラメーターをカーネルコマンドライン（grub.cfgなど）に追加することで、起動時にこれを設定できます。

例：

elevator=deadline

これにより、「期限」がすべてのブロックデバイスのデフォルトのI / Oスケジューラになります。

システムの起動後にスケジューラーを照会または変更する場合、または特定のブロックデバイスに別のスケジューラーを使用する場合は、ツールioschedsetをインストールして使用することをお勧めします。

https://github.com/kata198/ioschedset

Archlinuxを使用している場合は、aurで利用できます。

https://aur.archlinux.org/packages/ioschedset

使用例：

# Get i/o scheduler for all block devices
[username@hostname ~]$ io-get-sched
sda:    bfq
sr0:    bfq

# Query available I/O schedulers
[username@hostname ~]$ io-set-sched --list
mq-deadline kyber bfq none

# Set sda to use "kyber"
[username@hostname ~]$ io-set-sched kyber /dev/sda
Must be root to set IO Scheduler. Rerunning under sudo...

[sudo] password for username:
+ Successfully set sda to 'kyber'!

# Get i/o scheduler for all block devices to assert change
[username@hostname ~]$ io-get-sched
sda:    kyber
sr0:    bfq

# Set all block devices to use 'deadline' i/o scheduler
[username@hostname ~]$ io-set-sched deadline
Must be root to set IO Scheduler. Rerunning under sudo...

+ Successfully set sda to 'deadline'!
+ Successfully set sr0 to 'deadline'!

# Get the current block scheduler just for sda
[username@hostname ~]$ io-get-sched sda
sda:    mq-deadline

使用法は自明である必要があります。ツールはスタンドアロンであり、bashのみが必要です。

お役に立てれば！

編集：免責事項、これらは私が書いたスクリプトです。

Question 6

Linuxカーネルは、実行時にIOスケジューラを自動的に変更しません。つまり、今日のLinuxカーネルは、セカンダリストレージデバイスのタイプに応じて「最適な」スケジューラを自動的に選択することはできません。起動時または実行時に、IOスケジューラを手動で変更することができます。

デフォルトのスケジューラーは、/ linux - 2.6 / block / Kconfig.ioschedにあるファイルの内容に基づいて起動時に選択されます。ただし、echo有効なスケジューラ名を/ sys / block / [DEV] / queue / scheduleerにあるファイルに入力することにより、実行時にIOスケジューラを変更することができます。例えば、echo deadline > /sys/block/hda/queue/scheduler