...
ウェブホスティングのロゴ

I/O スケジューラ Linux：Noop、mq-deadline、BFQ のホスティングにおける説明

I/O スケジューラ Linux は、システムが SSD、NVMe、および HDD への読み取りおよび書き込みアクセスをどのようにソートし、優先順位付けし、デバイスに送信するかを決定します。このガイドでは、実践的な観点から、いつ Noop, mq-デッドライン そして BFQ ホスティングにおいて最良の選択である – チューニング、テスト、明確なアクションステップを含む。.

中心点

  • Noop: SSD/NVMe および VM でのオーバーヘッドを最小限に抑えます。
  • mq-デッドライン: サーバー向けのバランスのとれたレイテンシとスループット
  • BFQ: マルチユーザーにおける公平性と迅速な対応
  • blk-mq: 現代的なハードウェアのためのマルチキュー設計
  • チューニング: 固定ルールではなく、ワークロードごとのテスト

Linux ホスティングにおける I/O スケジューラの機能

Linux I/Oスケジューラは、I/Oリクエストをキューに割り当て、マージを実行し、デバイスへの配信を決定します。 レイテンシー を削減し、スループットを向上させます。最新のカーネルは、複数の CPU コアが並行して I/O を起動できるように、blk-mq、つまりマルチキューを使用しています。これは、多くのキューと高い並行性を提供し、キューを短縮する NVMe SSD に適しています。 ホスティングでは、多くの場合、幅広い混合負荷が発生します。Web サーバーは多くの小さな読み取りを実行し、データベースは同期書き込みを生成し、バックアップはストリームを生成します。適切なスケジューラは、輻輳を軽減し、応答時間を安定させ、保護します。 サーバー負荷下での経験。.

blk-mq の実践：none 対 noop およびカーネルのデフォルト設定

カーネル 5.x 以降、マルチキュー設計が標準パスとなっています。この設計では、 なし blk-mq の「Noop」に相当するもので、 noop 歴史的にはシングルキューパスに由来します。NVMe デバイスでは、ほとんどの場合 なし 利用可能。SATA/SAS ではよく見られる。 mq-デッドライン, 、オプション bfq また、ディストリビューションによっては kyber. デフォルトは様々です。NVMe は通常、 なし, 、SCSI/SATA は多くの場合 mq-デッドライン. そのため、私は常に利用可能なオプションを cat /sys/block//queue/scheduler そして、デバイスごとに決定します。どこだけ なし 選択可能であるのは意図的なものです。追加のソートは、実質的に何の付加価値も生まないからです。.

サーバーでのNoopの使用：ミニマリズムが勝つとき

Noop は主に隣接するブロックの結合を実行しますが、ソートは実行しないため、CPU のオーバーヘッドが非常に大きくなります。 ロー SSD および NVMe では、コントローラとファームウェアが賢い順序を処理するため、カーネルで追加のソートを行うことはほとんど意味がありません。 VM やコンテナでは、ハイパーバイザーが全体的な計画を立てるため、私はよく Noop を計画します。回転ディスクでは、ソートを行わないとシーク時間が長くなるため、Noop は使用しません。ハードウェアのコンテキストを確実に区別したい場合は、まずメモリのタイプを確認してください。ここでは、以下を確認するとよいでしょう。 NVMe、SSD、HDD, スケジューラを起動する前に festlege.

mq-deadline：期限、順序、明確な優先順位

mq-deadline は、読み取りアクセスに短いデッドラインを設定し、書き込みアクセスにはもう少し長い待ち時間を設定します。 応答時間 顕著に確保します。また、スケジューラはブロックアドレスでソートするため、検索時間が短縮され、特に HDD や RAID アレイに有効です。Web およびデータベースホストでは、mq-deadline はレイテンシとスループットのバランスに優れています。 ワークロードが混在し、読み取りと書き込みの両方が継続的に発生している場合に、この機能を使用するのが好きです。微調整のために、リクエストの深さ、ライトバックの動作、およびコントローラキャッシュをチェックして、デッドラインロジックが常に一貫していることを確認します。 グラブ.

BFQ：多数の同時ユーザーに対する公平性と応答性

BFQ は帯域幅を比例的に分配し、プロセスごとに予算を割り当てます。これにより、 フェア 多くのユーザーが同時に I/O を生成する場合に効果を発揮します。管理シェル、エディタ、API コールなどの対話型タスクは、バックグラウンドでバックアップが実行されている場合でも、高速に動作し続けます。 BFQ は、シーケンシャルフェーズを活用し、短いアイドルウィンドウを賢く利用するため、HDD では高い効率を発揮することがよくあります。非常に高速な SSD では、わずかな追加コストが発生しますが、それは顕著な反応性の向上と相殺されると思います。Cgroups および ioprio を使用している場合は、BFQ を使用して明確な保証を確立し、騒がしい隣人によるトラブルを回避することができます。 避ける.

日常におけるQoS：ioprio、ionice、およびBFQを備えたCgroups v2

クリーン用 優先順位付け BFQ をプロセスおよび Cgroup ルールと組み合わせています。プロセスレベルでは、 ionice クラスと優先順位： ionice -c1 （リアルタイム）レイテンシが重要な読み取り用, ionice -c2 -n7 （ベストエフォート、低）バックアップやインデックス実行用, ionice -c3 (アイドル) は、アイドル時間のみに実行すべきものすべてに使用します。Cgroups v2 では、私は io.weight 相対的な割合（例：100 対 1000）および io.max 厳しい制限について、例えば echo "259:0 rbps=50M wbps=20M" > /sys/fs/cgroup//io.max. BFQ を使用すると、重みが帯域幅の割合に非常に正確に変換されます。これは、共有ホスティングやコンテナホストに最適です。 公平性 最大出力よりも重要なもの。.

実践比較：どの選択肢がハードウェアに適しているか

選択はストレージのタイプとキューのアーキテクチャに大きく依存するため、まず以下を確認します。 装置 およびコントローラ。SSD および NVMe は、ほとんどの場合 Noop/none の恩恵を受け、HDD は mq-deadline または BFQ でより円滑に動作します。RAID セットアップ、SAN、およびオールラウンドホストでは、デッドラインロジックとソートが調和するため、私は mq-deadline を好んで使用します。 多くの対話型セッションがあるマルチユーザー環境では、BFQ が有利になる場合が多いです。以下の表は、その長所と適切な使用分野をわかりやすくまとめたものです。 一緒に:

スケジューラ ハードウェア 強み 弱点 ホスティングのシナリオ
Noop/なし SSD、NVMe、VM 最小限のオーバーヘッド、クリーンなマージ HDD上でソートを行わないと不利になる フラッシュサーバー、コンテナ、ハイパーバイザー制御
mq-デッドライン HDD、RAID、オールラウンドサーバー 厳格な読み取り優先度、ソート、安定したレイテンシ Noopよりも論理的 データベース、Webバックエンド、混合負荷
BFQ HDD、マルチユーザー、デスクトップ型ホスト 公平性、反応の良さ、優れたシーケンス 超高速SSDではオーバーヘッドが若干増加 インタラクティブサービス、共有ホスティング、開発サーバー

設定：スケジューラを確認し、永続的に設定する

まず、どのスケジューラがアクティブかを確認します。たとえば、次のように入力します。 cat /sys/block/sdX/queue/scheduler, 、そしてそれを書き留めてください。 オプション 角括弧で囲みます。一時的に変更するには、例えば次のように記述します。 echo mq-deadline | sudo tee /sys/block/sdX/queue/scheduler. 。永続的な設定には、udev ルールやカーネルパラメータを使用しています。 scsi_mod.use_blk_mq=1 そして mq-デッドライン コマンドラインで。NVMe デバイスでは、以下のパスを確認します。 /sys/block/nvme0n1/queue/ そして、デバイスごとに選択を設定します。重要：メンテナンスやロールバックの際に推測で作業することにならないよう、変更内容を記録しています。 成功する.

運用における持続性と自動化

日常では、自動化よりも再現性を重視しています。3つの方法が効果的であることが証明されています。

  • udevルール: すべての HDD の例 (回転=1) echo 'ACTION=="add|change", KERNEL=="sd*", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"' > /etc/udev/rules.d/60-io-scheduler.rules, 、それから udevadm control --reload-rules && udevadm trigger.
  • systemd-tmpfiles特定のデバイスについては、以下を定義します。 /etc/tmpfiles.d/blk.conf 次のような行で w /sys/block/sdX/queue/scheduler - - - - mq-deadline, ブート時に書き込むもの。.
  • 構成管理Ansible/Salt でデバイスクラス（NVMe、HDD）を作成し、ドキュメントやロールバックを含む一貫したデフォルト設定を配布します。.

注： エレベーター= カーネルパラメータは、古いシングルキューパスに適用されました。blk-mq では、選択を決定します。 1台あたり. スタック（dm-crypt、LVM、MD）では、トップデバイスにデフォルトを設定します。詳細については、以下をご覧ください。.

ホスティングにおけるワークロード：パターンを認識し、適切に対処する

まず、負荷を分析します。多くの小さな読み取りは Web フロントエンド、同期の多い書き込みはデータベースやログパイプライン、大きな順次ストリームはバックアップや アーカイブ. ツールとしては、 iostat, vmstat そして blktrace キュー、レイテンシ、マージ効果を示します。I/O による顕著な CPU アイドル時間については、以下を参照してください。 I/O待機を理解する, ボトルネックを体系的に解消するためです。その後、1～2人のスケジューラー候補者を同一の時間枠でテストします。直感ではなく、測定結果によって決定します。 神話.

測定手法の深化：再現性のあるベンチマーク

信頼性の高い意思決定のために、私は管理された fio-プロファイルを作成し、実際のアプリケーションテストで確認してください。

  • ランダムリード (ウェブ/キャッシュ): fio --name=rr --rw=randread --bs=4k --iodepth=32 --numjobs=4 --runtime=120 --time_based --filename=/mnt/testfile --direct=1
  • ランダムミックス (DB): fio --name=randmix --rw=randrw --rwmixread=70 --bs=8k --iodepth=64 --numjobs=8 --runtime=180 --time_based --direct=1
  • 順次 (バックアップ): fio --name=seqw --rw=write --bs=1m --iodepth=128 --numjobs=2 --runtime=120 --time_based --direct=1

同時に、私はログインします。 iostat -x 1, pidstat -d 1 P95/P99レイテンシを記録する fio. 詳細な診断には、私は blktrace または eBPF ツールなど バイオレイテンシー 重要：私は同じ時間帯、同じ負荷ウィンドウ、同じファイルサイズで測定しています。キャッシュの影響は、 direct=1 およびクリーンな事前条件（例：ボリュームの事前入力）。.

ファイルシステムとI/Oスケジューラ：相互作用が重要です

ファイルシステムはI/Oの特性に影響を与えるため、ジャーナルモード、キューの深さ、同期の挙動を厳しくチェックしています。 まさに. EXT4 と XFS は mq-deadline で効率的に動作しますが、ZFS は多くのことを自身でバッファリングおよび集約します。ZFS を搭載したホストでは、ZFS がすでに出力を形成しているため、スケジューラの影響がしばしば少ないことを観察しています。比較には、同一のマウントオプションとワークロードを使用しています。オプションを検討する場合は、以下をご覧ください。 EXT4、XFS、または ZFS 有益な視点 ストレージ-チューニング。.

ライトバック、キャッシュ、障壁：見過ごされがちな半分

スケジューラは、ライトバックサブシステムが許容する範囲でのみ効果を発揮します。そのため、私は常に以下を確認しています。

  • dirtyパラメータ: sysctl vm.dirty_background_bytes, vm.dirty_bytes, vm.dirty_expire_centisecs カーネルの書き込みのタイミングと積極性を制御します。データベースの場合、P99 を安定させるためにバーストのピークを下げることがよくあります。.
  • 障壁/フラッシュ: EXT4などのオプション 障壁 または XFS デフォルトのフラッシュは、ハードウェア（BBWC など）がそれを引き継ぐ場合にのみバックアップします。「nobarrier」は、電力保護機能がないため 危険な.
  • デバイス書き込みキャッシュ: コントローラの書き込みキャッシュ設定を確認します。 fsync 実際にメディアに保存され、キャッシュに保存されるだけではない。.

Writeback を平滑化すると、スケジューラの負荷が軽減されます。デッドラインは確実に守られ、BFQ は突然のフラッシュの波に対処する作業が少なくて済みます。.

仮想化、コンテナ、クラウド：実際に計画しているのは誰？

VM では、ハイパーバイザーが物理的な I/O フローを制御するため、ゲストでは Noop/none をよく選択して重複を回避しています。 論理学 避けるべき。ホスト自体では、デバイスやタスクに応じて mq-deadline または BFQ を使ってるよ。クラウドボリューム（ネットワークブロックストレージなど）の場合、計画の一部はバックエンドにあるから、仮定に頼るよりも実際のレイテンシを測ってる。負荷が大きく混在するコンテナホストの場合、BFQ の方がインタラクティブ性が良いことが多いね。 フラッシュのみの均質なバッチクラスタでは、すべての CPU 時間が重要であり、コントローラが効率的であるため、Noop が主流となっています。 仕事.

RAID、LVM、MD、マルチパス：スケジューラが機能する場所

積み重ねられたブロックスタックで、スケジューラを トップデバイス 関連するキューがそこにあるからです。

  • LVM/dm-crypt: スケジューラ /dev/dm-* それぞれ /dev/mapper/ 設定します。物理的な PV は、ほとんどの場合 なし, マージ/ソートが二重に行われないようにするためです。.
  • MD-RAID: /dev/mdX 決定する；その下にある sdX デバイスは静かに動作し続けます なし. ハードウェア RAID は、単一のブロックデバイスとして扱われます。.
  • マルチパスマルチパスマッパー (/dev/mapper/mpatha) を設定します。その下のパスデバイスは なし.

重要：私はテストを以下のように分けます。 プール および冗長性レベル（RAID1/10 対 RAID5/6）。パリティ RAID はランダム書き込みに対してより敏感に反応します。この点では、mq-deadline は一貫した読み取りデッドラインと整然とした出力によって、多くの場合優位に立っています。.

チューニング戦略：信頼性の高いパフォーマンスへのステップバイステップ

基本測定から始めます：現在の応答時間、スループット、95/99パーセンタイル、CPU負荷. その後、通常はスケジューラという1つの要素のみを変更し、同じ負荷を再度実行します。以下のようなツールを使用します。 fio 制御して支援しますが、私は実際のアプリケーションテストで各仮説を確認しています。データベースには、トランザクションと fsync 動作を反映した独自のベンチマークが適しています。測定値が安定してから初めて、選択内容を確定し、それを文書化します。 なぜ.

キューの深さ、先読み、CPU アフィニティ

スケジューラに加えて、キューパラメータも実務に大きな影響を与えます。

  • キューの深さ: /sys/block//queue/nr_requests ハードウェアキューごとの保留リクエストを制限します。NVMe は深いキュー（高いスループット）に対応し、HDD は適度な深さのキュー（より安定したレイテンシ）でメリットを発揮します。.
  • 先読み: /sys/block//queue/read_ahead_kb それぞれ blockdev --getra/setra. 。シーケンシャルなワークロードの場合は少し高く、ランダムなワークロードの場合は低く設定してください。.
  • rq_affinityと /sys/block//queue/rq_affinity 2 では、I/O 完了が優先的に生成元の CPU コアで処理されるようにします。これにより、クロス CPU コストが削減されます。.
  • 回転: SSDが動作することを確認します。 回転=0 カーネルが HDD ヒューリスティックを適用しないように報告する。.
  • マージ: /sys/block//queue/nomerges マージを削減できます（2=オフ）。NVMeのマイクロレイテンシには有効ですが、HDDではほとんどの場合、不利になります。.
  • io_poll (NVMe): ポーリングはレイテンシを低減できますが、CPU を必要とします。私は、特定の状況でこれを有効にします。 低遅延-必要条件

スケジューラ・チューナブルの詳細

スケジューラに応じて、適切な微調整が可能である。

  • mq-デッドライン: /sys/block//queue/iosched/read_expire (ms、通常は小さい), write_expire （大きい）, fifo_batch (バッチサイズ), front_merges (0/1)。私は read_expire P95リードを保護するために短縮し、調整する fifo_batch デバイスによって異なります。.
  • BFQ: slice_idle （シーケンス使用のためのアイドル時間）, 低遅延 (0/1) 反応の良い双方向性。 bfq.weight Cgroups では、相対的な割合を非常に細かく制御しています。.
  • none/noop: 調整ネジはほとんどありませんが、 周辺環境 （キューの深さ、リードアヘッド）が結果を決定します。.

私は常に1つのパラメータのみを変更し、その変更を厳密に記録しています。そうすることで、どの変更がどのような効果をもたらしたかが明確になります。.

よくある落とし穴とそれを回避する方法

RAID コントローラの後ろにある HDD と SSD の混合プールはテスト結果を歪めるため、測定は個別に行います。 グループ. スケジューラはブロックデバイスごとに適用されるということを忘れないでください。LVMマッパーとMDデバイスは別々に扱います。永続性は失われやすいものです。udevルールやカーネルパラメータがない場合、再起動後にデフォルト設定に戻ります。CgroupsやI/O優先度は、公平性を大幅に高めるにもかかわらず、多くの場合利用されません。 また、選択したロジックが潜在能力を最大限に発揮できるよう、キューの深さ、ライトバック、ファイルシステムオプションを常に確認しています。 ショー.

トラブルシューティング：症状を的確に読み取る

測定値が変化した場合、私はパターンを解釈し、具体的な対策を導き出します。

  • 多くのリードで高い P99 レイテンシ書き込みが読み取りを圧迫していないか確認する。mq-deadline でテストする。, read_expire 低下、ライトバックの平滑化 (vm.dirty_* 調整する）。.
  • 100% HDD上のユーティリティ、低スループット: シークを支配する。BFQ または mq-deadline を試す、リードアヘッドを削減する、キューの深さを適度に保つ。.
  • スループットは良好だが、UIがぎこちないインタラクティブ性が損なわれます。BFQを有効にし、重要なサービスを ionice -c1 または Cgroup の重み付けを優先します。.
  • 時間帯によって大きな変動がある: 共有リソース。Cgroups で分離し、プールごとにスケジューラを選択し、バックアップをオフピーク時に移行します。.
  • dmesg における NVMe タイムアウト：バックエンドまたはファームウェアの問題。. io_poll テスト的に無効にし、ファームウェア/ドライバを確認し、パス冗長性（マルチパス）を検証してください。.

簡単にまとめると：日常的なホスティング業務における明確な決定

フラッシュストレージとゲストについては、私はよく以下を選択します。 Noop, オーバーヘッドを節約し、コントローラを動作させるためです。HDD または RAID を搭載したオールラウンドサーバーでは、mq-deadline が信頼性の高いレイテンシと高い可用性を提供します。アクティブユーザーが多く、インタラクティブな負荷がかかる場合、BFQ は公平な割り当てと顕著な応答性を実現します。 私は、固定化する前に実際のワークロードを測定し、P95/P99 への影響を確認しています。これにより、理解できる決定を下し、システムを迅速に維持し、安定化を図っています。 サーバー-日常業務におけるパフォーマンス。.

現在の記事