Noop スケジューラ

NOOP スケジューラは、 Linuxカーネル用の最もシンプルなI/O スケジューラです。このスケジューラはJens Axboeによって開発されました。

概要

NOOP スケジューラは、すべての着信 I/O 要求を単純なFIFOキューに挿入し、要求のマージを実装します。このスケジューラは、ホストがそこに含まれるセクター番号に基づいて要求の順序を変更しないように決定されている場合に役立ちます。言い換えると、スケジューラは、ホストが要求を効率的に順序変更する方法を認識していないと想定します。

この状況が望ましい基本的な状況は (一般的に) 3 つあります。

I/O スケジューリングが I/O スタックの下位層で処理される場合。スケジューリングを処理する下位層の例としては、ブロックデバイス、インテリジェント RAID コントローラ、ネットワーク接続ストレージ、またはスイッチストレージエリアネットワークを介してアクセスされるストレージサブシステムなどの外部接続コントローラなどがあります。^[1] I/O 要求は下位レベルで再スケジュールされる可能性があるため、ホストレベルで IOP を再シーケンスすると、下位レベルで元に戻される操作にホスト CPU 時間が使用されます。これにより、生産的な理由もなくレイテンシが増加し、スループットが低下します。
セクター位置の正確な詳細はホストシステムから隠されているためです。例としては、独自にスケジュールを実行しない RAID コントローラが挙げられます。ホストには要求の順序を変更する機能があり、RAID コントローラにはその機能がありませんが、ホストシステムには要求を正確に順序変更してシーク時間を短縮するための可視性がありません。ホストには、あるシーケンスが別のシーケンスよりも優れているかどうかを判断する方法がないため、アクティブキューを最適に再構築できず、したがって、(理論上) より詳細に認識しているデバイスに渡す必要があります。
読み取り/書き込みヘッドの移動は、並べ替えのオーバーヘッドを正当化するほどアプリケーションのパフォーマンスに影響を与えないためです。これは通常、フラッシュドライブやソリッドステートドライブ(SSD) などの非回転メディアの場合に当てはまります。

ただし、NOOP は必ずしも上記のシナリオに適した I/O スケジューラではありません。パフォーマンスチューニングではよくあることですが、すべてのガイダンスは、観察された作業負荷パターンに基づいて行われます (単純な経験則を作成する能力を損なう)。他のアプリケーションから利用可能な I/O 帯域幅の競合がある場合、他のスケジューラは、最も重要と思われるアプリケーションにその帯域幅をよりインテリジェントに分割することで、より良いパフォーマンスを生み出す可能性があります。たとえば、LDAP ディレクトリサーバーを実行すると、deadlineの読み取り優先度とレイテンシ保証のメリットが得られます。同時に、さまざまなアプリケーションを実行するデスクトップシステムのユーザーは、CFQの調整可能パラメータや、特定のアプリケーションの帯域幅を他のアプリケーションよりも優先する機能 ( ionice ) にアクセスしたい場合があります。

アプリケーション間に競合がない場合、上記の 3 つのシナリオでスケジューラを選択するメリットはほとんどありません。これは、1 つのワークロードの操作の優先順位を下げて、別のワークロードに追加の容量を使用できるようにすることができないためです。言い換えると、I/O パスが飽和しておらず、すべてのワークロードの要求によってドライブヘッドが不当に移動されない場合 (オペレーティングシステムはこれを認識しています)、1 つのワークロードを優先するメリットによって、I/O のスケジュール設定に費やされる CPU 時間が無駄になり、望ましいメリットが得られない状況が発生する可能性があります。

Linuxカーネルは、nomerges sysfsパラメータをスケジューラに依存しない構成として公開し、ブロック層のリクエストマージロジックを完全に無効にしたり、より複雑なマージ試行に対してのみ無効にしたりすることができます。^[2] ほとんどのI/Oスケジューラのオーバーヘッドは、リクエストキュー内の隣接セクターを見つけてマージしようとする試みと関連しているため、これによりNOOPスケジューラの必要性が軽減されます。ただし、ほとんどのI/Oワークロードは、SSDなどの高速で低レイテンシのストレージであっても、一定レベルのリクエストマージから恩恵を受けます。^[3]^[4]

参照

参考文献

^ 「Red Hat Enterprise Linux 4 および 2.6 カーネル用の I/O スケジューラの選択」。Red Hat。2007 年 8 月 27 日のオリジナルからアーカイブ。2007 年8 月 10 日に取得。
^ "Documentation/block/queue-sysfs.txt". Linuxカーネルドキュメント. kernel.org . 2014年12月1日. 2014年12月14日閲覧。
^ 「6.4.3. Noop (Red Hat Enterprise Linux 6 ドキュメント)」。Red Hat。2014年 10 月 8 日。2014 年12 月 14 日閲覧。
^ Paul Querna (2014 年 8 月 15 日)。「高 I/O インスタンスのフラッシュドライブをデータドライブとして構成する」。Rackspace。2014年12月 15 日閲覧。

外部リンク

ディスクI/Oの理解と最適化
Linux 2.6 I/O スケジューラのワークロード依存パフォーマンス評価
カーネルベースの仮想マシンのベストプラクティス (I/O スケジューラに関する一般的な情報を提供します)
Linux I/O スケジューラのベンチマーク – 予測 vs. CFQ vs. 期限 vs. noop

[1] 「Red Hat Enterprise Linux 4 および 2.6 カーネル用の I/O スケジューラの選択」。Red Hat。2007 年 8 月 27 日のオリジナルからアーカイブ。2007 年8 月 10 日に取得。

[2] "Documentation/block/queue-sysfs.txt". Linuxカーネルドキュメント. kernel.org . 2014年12月1日. 2014年12月14日閲覧。

[3] 「6.4.3. Noop (Red Hat Enterprise Linux 6 ドキュメント)」。Red Hat。2014年 10 月 8 日。2014 年12 月 14 日閲覧。

[4] Paul Querna (2014 年 8 月 15 日)。「高 I/O インスタンスのフラッシュドライブをデータドライブとして構成する」。Rackspace。2014年12月 15 日閲覧。