Linux I/Oスケジューラのチューニング：mq-deadline、none、およびBFQ

LinuxのI/Oスケジューラは、読み取りおよび書き込みリクエストがストレージデバイスに到達する順序を決定します。適切な選択は、ほぼ完全にハードウェアに依存します。 none をNVMe用として、 mq-deadline を、混合ワークロードを実行するSATA SSDおよびHDDには bfq は、あるプロセスが他のプロセスのリソースを独占するのを防ぐ必要がある場合に使用します。このガイドでは、3つの主要なスケジューラの仕組み、ワークロードに合わせたスケジューラの選定方法、およびチューニングと結果の検証方法について解説します。

読む前に実際に操作してみたい場合は、この動画で、ターミナルからスケジューラを切り替えたりテストしたりする基本手順を確認できます。

mq-deadline、none、BFQの違い

各スケジューラは、それぞれ異なる戦略でリクエストを処理します。これらの違いを理解することで、起動時にカーネルが選択したものをそのまま使用するのではなく、意図的に選択することが可能になります。

mq-deadline

この mq-deadline スケジューラは、どのリクエストも無限に待機しないようにします。読み取りと書き込み用に別々のソート済みキューを維持し、シーク時間を短縮するために論理ブロックアドレス（LBA）順に並べ替え、デフォルトで読み取りは500ミリ秒、書き込みは5秒というデッドラインを強制します。リクエストがデッドラインに達すると、キューの先頭に移動します。

読み取りは書き込みよりも優先されます。これは、書き込みが非同期で処理されるのに対し、読み取りは通常アプリケーションをブロックするためです。書き込みが完全に飢餓状態に陥るのを防ぐため、スケジューラは一定数の読み取り処理後に、期限切れの書き込みバッチを処理します。その結果、一貫して低レイテンシが実現され、データベースサーバーや、読み取りと書き込みが混在するあらゆるワークロードに最適です。

なし

この none スケジューラはほとんど何も行いません。リクエストを先入れ先出し（FIFO）順で、再順序付け、マージ、優先順位付けなしにデバイスへ直接渡します。これは、独自の内部キューを管理し、一度に数万件の処理中のリクエストを追跡できる最新のNVMeドライブに適しています。ソフトウェアによるスケジューリング層を排除することで、アプリケーションからデバイスへの最短経路が実現され、これはまさに高スループットのNVMeワークロードが求めるものです。

ただし、これはハードウェアが独自にインテリジェントなスケジューリングを行える場合にのみ有効です。キューの深さが浅いHDDやSATA SSDでは、ソフトウェアによるリオーダーを省略すると、通常、パフォーマンスは向上するどころか低下してしまいます。

BFQ

BFQ（Budget Fair Queuing）は公平性を最優先します。タイムスライスではなく、各プロセスにディスクセクタ単位で測定された「予算」を割り当てます。スループットを維持するために、大規模なシーケンシャル読み取りには大きな予算が割り当てられ、レイテンシに敏感なタスクには迅速に処理されるよう小さな予算が割り当てられます。また、フィードバックループによって実行中に予算が調整されます。

BFQは、高負荷下でも対話型タスクの応答性を維持するため、バックグラウンドで大規模なファイル転送が実行されている間も、動画再生やデータベースクエリはスムーズに動作し続けます。しかし、その公平性を確保するにはCPUリソースを消費します。リクエストごとのオーバーヘッドは約1.9マイクロ秒で、mq-deadlineの約3倍であり、低速なARMコアでは、そのオーバーヘッドによってスループットが、高速なx86チップ上で同じスケジューラが達成する値を大きく下回ってしまいます。 生のスループットとCPU効率が最も重要視されるサーバー環境では、このトレードオフを正当化するのは困難です。

ワークロードに適したスケジューラの選定

適切なスケジューラを決める要素は2つあります。ストレージハードウェアと、アプリケーションのアクセスパターンです。まずはハードウェアから見ていきましょう。ファームウェアの機能によりリクエストの再順序付けが既に実行されているデバイス（例：NVMeドライブ）の場合、ソフトウェアによるスケジューリングはオーバーヘッドを増やすだけなので、 none が優位となります。シーク時間が支配的な回転式HDDでは、ソフトウェアによるリオーダーがレイテンシを低減するため、 mq-deadline または bfq が適しています。SATA SSDは中間に位置します。HDDより高速ですが、NVMeのような深いキューを持たないため、 mq-deadline が適しています。

他の何かがすでにスケジューリングを行っている場合にも、同じ論理が適用されます。virtio-blk上のゲストVMはホストにI/Oスケジューリングを依存しており、ライトバックキャッシュを備えたハードウェアRAIDコントローラは独自の順序付けを最適化します。どちらの場合も none は、同じ処理に二重にコストをかけることを回避します。

2つ目の要因はアクセスパターンです。1秒あたり数千回のランダムな4K読み取りを行うデータベースと、NVMeアレイから大きな連続ブロックをストリーミングするトレーニングジョブとは共通点がなく、それぞれ異なるスケジューラを必要とします。以下の表は、一般的なワークロードと適切な出発点を対応させたものです。

特筆すべき例外が1つあります。NVMeであっても、金融システムなどにおいてp99やp999のテールレイテンシが重要な指標となる場合、 mq-deadline は none 厳格な締切を課し、時折発生するリクエストの遅延を防ぐことで、

スケジューラパラメータの変更と調整

スケジューラの切り替えおよびパラメータの調整は、いずれも sysfs を通じて行われ、変更をテストするために再起動は必要ありません。

アクティブなスケジューラの切り替え

デバイスで利用可能なスケジューラを確認します。括弧内の値がアクティブなスケジューラです：

cat /sys/block/sda/queue/scheduler

実行時に別のスケジューラに切り替えます。これは即座に有効になりますが、再起動後は設定が保持されません：

echo bfq | sudo tee /sys/block/sda/queue/scheduler

もし bfq がリストにない場合は、まずモジュールをロードしてください:

sudo modprobe bfq

設定を永続化するには、旧式の elevator= カーネルパラメータの代わりにudevルールを使用してください。RHEL 9および同様のリリースでは、このパラメータではスケジューラを変更できなくなっています。このルールは、 mq-deadline をすべての非回転式SCSIディスクに対して設定します /etc/udev/rules.d/60-io-scheduler.rules:

ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"

再起動せずに読み込んで適用するには：

sudo udevadm control --reload-rules && sudo udevadm trigger

RHELベースのシステムでは、TuneDプロファイルが、デバイスごとのルールではなく、システム全体のプロファイルを通じて同様の機能を提供します。

調整すべきパラメータ

各スケジューラは、 /sys/block/<device>/queue/iosched/の下に公開しています。 mq-deadlineの場合、デッドラインが主な調整項目となります。SATA SSD上のレイテンシに敏感なデータベースでは、デッドラインを短く設定すると効果的です:

echo 100 | sudo tee /sys/block/sda/queue/iosched/read_expire
echo 1000 | sudo tee /sys/block/sda/queue/iosched/write_expire

一方 bfq 高スループットシステムでは、レイテンシのヒューリスティックを無効にするとスループットが向上します：

echo 0 | sudo tee /sys/block/sda/queue/iosched/low_latency
echo 0 | sudo tee /sys/block/sda/queue/iosched/slice_idle

共有ホスティングの場合、BFQはcgroups v2との相性が良い。 io.weight 値を設定することで、例えばデータベースプロセスにバックアップジョブの10倍のI/Oシェアを割り当てることができ、バックグラウンド作業が対話型トラフィックを圧迫するのを防げます。どのような変更を行うにせよ、BFQのリクエストごとのコストは高いため、CPUに負荷がかかり、IOPSの高いシステムではそのコストが累積します。そのため、適用する前にベンチマークテストを行うことをお勧めします。

チューニング後のパフォーマンス確認

何かを変更する前に、必ずベースラインを測定してください。ベースラインがなければ、調整が有効だったかどうかを判断する手段がありません。

fioは、このための標準的なツールです。fioは、ブロックサイズ、キュー深度、およびI/Oエンジンの設定を通じて、特定のワークロードパターンを再現します。常に --direct=1 引数を与えて実行し、ページキャッシュをバイパスして、キャッシュされた読み取りではなく、スケジューラとデバイスを直接測定するようにしてください。テストを実際のワークロードに合わせてください：

1 から 256 までの値で同じテストを実行し iodepth 1 から 256 までの値で同じテストを実行し、デバイスの飽和点（IOPS の上昇が止まり、レイテンシが急上昇するポイント）を特定します。変更後のリアルタイム監視については、 iostat -x 1 重要なメトリクスを報告します： r_await および w_await 読み取りおよび書き込み完了レイテンシ、 aqu-sz 平均キュー深度、および %util デバイス使用率。 %util が100パーセント近くにある場合、ハードウェアがボトルネックとなっており、スケジューラの変更では改善できません。

ソフトウェアのコストとハードウェアのコストを区別するには、bttオプションを指定してblktraceを実行します。これにより、レイテンシがQ2D（ソフトウェアキューでの待機時間）とD2C（デバイスがリクエストを処理する時間）に分割されます。Q2Dが支配的であれば、スケジューラがボトルネックです。D2Cが支配的であれば、ハードウェアがボトルネックです。

結果を読む際に留意すべき点として、スケジューラの選択は主にレイテンシ分布の「尾部」に影響を与え、中央値には影響しないという点があります。 none から mq-deadline に変更すると、中央値のレイテンシが数マイクロ秒上昇する一方で、p99およびp999のレイテンシは半分に削減される可能性があります。SLAに縛られるユーザー向けサービスにとって、このトレードオフはほぼ常に価値があります。そのため、平均スループットではなく、レイテンシのテール部分を測定することが、この作業の真の目的となります。

適切なスケジューラの選定

スケジューラのチューニングとは、アルゴリズムをハードウェアやアクセスパターンに適合させ、測定によってその有効性を実証することです。要約すると：

• NVMe： none を使用し、キューイングはファームウェアに任せる。
• SATA SSDおよびI/Oが混在するHDD： mq-deadline を使用し、予測可能なレイテンシを確保する。
• 共有またはマルチテナントホスト： bfq を使用し、あるワークロードが他のワークロードのリソースを独占しないようにする。
• 中央値ではなく、テールレイテンシを測定する：スケジューラの変更は p99 および p999 に現れるため、これらを測定すべきです。
• 永続化させる：udevルールまたはTuneDを使用し、決して elevator= パラメータは絶対に使用しないでください。

スケジューラを最大限に活用するには、まずそれに追従できるハードウェアが必要です。高スループットかつ低レイテンシのワークロード向けに構築されたNVMe搭載サーバーが必要な場合は、FDCのVPSオプションをご検討ください。