blk-mqおよびI / Oスケジューラー

近年のストレージデバイスの分野では、大きな変化があります。新しい技術が導入され、ディスクドライブのボリュームと速度が成長しています。 この場合、次の状況が発生します。この状況では、ボトルネックはデバイスではなくソフトウェアにあります。 ディスクサブシステムを操作するためのLinuxカーネルメカニズムは、新しい高速ブロックデバイスにはまったく適していません。



Linuxカーネルの最近のバージョンでは、この問題を解決するために多くの作業が行われています。 バージョン4.12のリリースでは、ユーザーはブロックデバイス用にいくつかの新しいスケジューラーを使用する機会があります。 これらのスケジューラは、リクエストを送信する新しい方法- マルチキューブロック層 （blk- mq）に基づいています。



この記事では、新しいスケジューラーの機能と、ディスクサブシステムのパフォーマンスへの影響の詳細を調べたいと思います。



この記事は、負荷の高いシステムのテスト、実装、および管理に関わるすべての人にとって興味深いものになります。 従来のスケジューラと新しいスケジューラについて話し、合成テストの結果を分析し、負荷のテストとスケジューラの選択に関する結論を導きます。 理論から始めましょう。

理論のビット

従来、Linuxのブロックデバイスドライバーを操作するサブシステムは、ドライバーに要求を送信するための2つのオプションを提供しました。1つはキューあり、もう1つはキューなしです。



前者の場合、キューはデバイスへのリクエストに使用され、すべてのプロセスに共通です。 一方では、このアプローチにより、さまざまなスケジューラーを使用できるようになります。一般的なキューでは、要求を所定の場所に再配置し、一部を低速化し、他の要求を高速化し、隣接ブロックへの複数の要求を単一の要求に結合してコストを削減できます。 一方、ブロックデバイスからの処理要求の高速化により、このキューがボトルネックになります。これは、オペレーティングシステム全体に対するものです。



2番目の場合、要求はデバイスドライバーに直接送信されます。 もちろん、これにより一般的なキューをバイパスすることができます。 ただし、同時に、ターンを作成し、デバイスドライバー内で要求をスケジュールする必要があります。 このオプションは、要求を処理し、送信中に実際のデバイスにリダイレクトする仮想デバイスに適しています。



過去数年で、ブロックデバイスによるリクエストの処理速度が向上し、そのため、オペレーティングシステムとデータ転送インターフェイスの要件が変更されました。



2013年に、3番目のオプションであるマルチキューブロックレイヤー（blk-mq）が開発されました。

ソリューションのアーキテクチャを一般的な用語で説明します。 要求は最初にソフトウェアキューに入ります。 これらのキューの数は、プロセッサコアの数と同じです。 プログラムキューを渡した後、要求は送信キューに入ります。 送信キューの数は、1〜2048のキューをサポートできるデバイスドライバーに既に依存しています。 スケジューラーの作業はソフトウェアキューのレベルで実行されるため、ソフトウェアキューからの要求は、ドライバーが提供する送信キューに分類されます。

標準スケジューラ

最新のLinuxディストリビューションのほとんどには、 noop 、 CFQ、 deadlineの 3つの標準スケジューラが用意されています。



noopという名前は、このスケジューラーが何もしないことを示唆する、操作なしの略語です。 実際、これはそうではありません：noopは単純なFIFOキューを実装し、リクエストを隣接ブロックに結合します。 要求の順序は変更されず、これの基礎となるレベル、たとえばRAIDコントローラーの計画機能に依存します。



CFQ （完全に公平なキューイング）はより効果的に機能します。 すべてのプロセス間で帯域幅を共有します。 同期リクエストの場合、プロセスごとに順番に作成されます。 非同期リクエストは優先度によってキューに入れられます。 さらに、CFQはクエリをソートして、ディスクセクターの検索を最小限に抑えます。 キュー間でリクエストを実行する時間は、 ioniceユーティリティを使用して設定できる優先度に従って分配されます。 設定時に、プロセスクラスとクラス内の優先度の両方を変更できます。 設定について詳しくは説明しませんが、このスケジューラには非常に柔軟性があり、プロセスの優先順位を設定することは、ユーザーの管理タスクの実行を制限するのに非常に便利です。



締切スケジューラーは異なる戦略を使用します。 基準は、リクエストがキューにあった時間です。 したがって、すべてのリクエストがスケジューラによって処理されることが保証されます。 ほとんどのアプリケーションは読み取り時にブロックされるため、デフォルトでは、期限により読み取り要求が優先されます。



blk-mqメカニズムは、標準カーネルツールが必要なパフォーマンスを提供しないことが明らかになったNVMeディスクの出現後に開発されました。 カーネル3.13に追加されましたが、スケジューラは後で書かれました。 最新のLinuxカーネルバージョン（≥4.12）には、blk-mqの次のスケジューラーがあります：none、bfq、mq-deadline、およびkyber。 これらの各プランナーをより詳細に検討してください。

BLK-MQプランナー：概要

blk-mqを使用すると、スケジューラーを実際に無効にすることができます。スケジューラーをnoneに設定するだけです。



BFQについては多くのことが書かれていますが、CFQから設定とメインアルゴリズムの一部を継承し、予算の概念とチューニングのためのいくつかのパラメーターを導入しているとしか言えません。



Mq-deadlineは、ご想像のとおり、blk-mqを使用した期限の実装です。



最後のオプションはkyberです。 高速デバイスで動作するように書かれています。 書き込み要求と読み取り要求の2つのキューを使用して、kyberは書き込み要求よりも読み取り要求を優先します。 アルゴリズムは、各リクエストの完了時間を測定し、実際のキューサイズを調整して、設定で設定された遅延を実現します。

テスト

はじめに

スケジューラの確認はそれほど簡単ではありません。 単純なシングルスレッドテストでは、説得力のある結果は表示されません。 2つのテストオプションがあります。たとえば、fioを使用してマルチスレッドロードをシミュレートします。 実際のアプリケーションをインストールし、負荷がかかったときにそれがどのように表示されるかを確認します。



一連の合成テストを実施しました。 それらはすべて、スケジューラー自体の標準設定で実行されました（このような設定は、/ sys / block / sda / queue / iosched /にあります）。

どのケースをテストしますか？

ブロックデバイスにマルチスレッドの負荷を作成します。 最高のデータレートで最小の遅延（最小の遅延パラメーター）に関心があります。 読み取り要求が優先されると仮定します。

HDDテスト

hddでプランナーをテストすることから始めましょう。

HDDテストでは、サーバーが使用されました。

• 2 xIntel®Xeon®CPU E5-2630 v2 @ 2.40GHz
• 128 GB RAM
• 8TB HGST HUH721008ALディスク
• Ubuntu linux 16.04 OS、公式リポジトリのカーネル4.13.0-17-generic

Fioオプション

[global] ioengine=libaio blocksize=4k direct=1 buffered=0 iodepth=1 runtime=7200 random_generator=lfsr filename=/dev/sda1 [writers] numjobs=2 rw=randwrite [reader_40] rw=randrw rwmixread=40
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

設定から、キャッシュをバイパスし、各プロセスのキューの深さを1に設定することがわかります。 2つのプロセスがデータをランダムブロックに書き込みます。1つは書き込みと読み取りです。 reader_40セクションで説明されているプロセスは、読み取り要求の40％を送信し、残りの60％を書き込み要求に送信します（ rwmixreadオプション）。



fioオプションの詳細は、 manページに記載されています 。



テストの期間は2時間（7200秒）です。







従来の（単一キュー）スケジューラーのテスト結果を見てください。 テストの結果として得られた値は、実際には互いに異ならない。 デッドラインおよびヌープテストのグラフで見られるレイテンシバーストは、頻度は少ないもののCFQテストでも発生していることに注意してください。 blk-mqスケジューラーをテストするとき、これは観察されず、要求のタイプ（書き込みまたは読み取り）に関係なく、最大遅延は最大11秒に達しました。



blk-mq-schedulersを使用する場合、すべてがはるかに興味深いものになります。 データの読み取り要求の処理の遅延に主に関心があります。 このようなタスクのコンテキストでは、BFQはさらに悪くなります。 このスケジューラの最大遅延は、書き込みで6秒、読み取りで最大2.5秒に達しました。 遅延の最小最大値はkyberを示しました-書き込みで129ms、読み取りで136ms。 すべてのストリームで最大遅延が20ミリ秒増加します。 mq-deadlineの場合、書き込みには173ミリ秒、読み取りには289ミリ秒でした。



結果が示すように、スケジューラを変更しても遅延を大幅に削減することはできませんでした。 ただし、BFQスケジューラーを強調表示して、記録/読み取りデータの数の点で良好な結果を示したことができます。 一方、BFQテスト中に得られたグラフを見ると、fio側からの負荷が非常に均一で均一であるにもかかわらず、ディスク上の負荷の不均一な分布は奇妙に見えます。

SSDテスト

SSDテストでは、サーバーが使用されました。

• Intel®Xeon®CPU E5-1650 v3 @ 3.50GHz
• 64 GB RAM
• 1.6TB INTEL Intel SSD DC S3520シリーズ
• Ubuntu Linux 14.04 OS、カーネル4.12.0-041200-generic（ kernel.ubuntu.com ）

Fioオプション

 [global] ioengine=libaio blocksize=4k direct=1 buffered=0 iodepth=4 runtime=7200 random_generator=lfsr filename=/dev/sda1 [writers] numjobs=10 rw=randwrite [reader_20] numjobs=2 rw=randrw rwmixread=20
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

テストはhddの前のテストと似ていますが、ディスクにアクセスするプロセスの数が異なります-書き込み用に10、書き込みおよび読み取り用に2つ、80/20の書き込み/読み取り比率、およびキュー深度。 ドライブに1598GBのパーティションが作成され、2ギガバイトが未使用のままになりました。







平均読み取り遅延に注意してください。 すべてのプランナーの中で、遅延が最も少ないkyberと最大のCFQが際立っています。 Kyberは、高速デバイスで動作するように設計されており、一般に、同期リクエストを優先して、レイテンシを削減することを目的としています。 読み取り要求の場合、遅延は非常に小さく、読み取られるデータの量は他のスケジューラーを使用する場合よりも少なくなります（CFQを除く）。



kyberとデッドラインなどの1秒あたりの読み取りデータ数の違いと、読み取り遅延の違いを比較してみましょう。 kyberは、デッドラインの7分の1の読み取り遅延を示しましたが、読み取りスループットは1.2倍しか減少しませんでした。 同時に、kyberは書き込み要求に対して悪い結果を示しました-遅延が1.5倍増加し、スループットが1.3倍減少しました。



最初の目標は、帯域幅の損傷を最小限に抑えながら、読み取り遅延を最小限に抑えることです。 テスト結果によると、この問題を解決するには、kyberが他のプランナーよりも優れていると考えることができます。



CFQとBFQが比較的低い書き込み遅延を示したことに注目するのは興味深いですが、この場合、CFQを使用する場合、ディスクへの書き込みのみを実行するプロセスが最高の優先度を取得しました。 これからどのような結論を引き出すことができますか？ おそらく、開発者が発表したように、BFQはリクエストをより「正直に」優先します。



最大レイテンシは、* FQスケジューラとmq-deadlineではるかに長くなりました-CFQで最大〜3.1秒、BFQおよびmq-deadlineで最大〜2.7秒。 残りのプランナーでは、テスト中の最大遅延は35〜50ミリ秒でした。

NVMeテスト

NVMeテストでは、SSDテストが実行されたサーバーにMicron 9100がインストールされ、ディスクレイアウトはSSDに似ており、1598GBテストと2GBの未使用領域のセクションです。 fioの設定は前のテストと同じで、キューの深さ（iodepth）のみが8に増加しました。

 [global] ioengine=libaio blocksize=4k direct=1 buffered=0 iodepth=8 runtime=7200 random_generator=lfsr filename=/dev/nvme0n1p1 [writers] numjobs=10 rw=randwrite [reader_20] numjobs=2 rw=randrw rwmixread=20
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

グラフは、スケジューラの変更と一時停止を伴うテスト結果を示しています。 テスト順序：なし、kyber、mq-deadline、BFQ。



表とグラフでは、遅延を削減するためのkyberアルゴリズムのアクティブな操作が再び表示されます：他のスケジューラーの1.3-1.4に対して0.612ms。 NVMeディスクにスケジューラーを使用するのは理にかなっていないと一般に考えられていますが、優先順位がレイテンシーを減らすことであり、I / O操作の数を犠牲にできる場合は、kyberを検討することは理にかなっています。 グラフを見ると、BFQを使用するとCPUの負荷が増加することがわかります（最後のテスト）。

結論と推奨事項

この記事は、このトピックの非常に一般的な紹介です。 そして、私たちのテストからのすべてのデータは、実際にはすべてが実験条件よりもはるかに複雑であるという事実を考慮に入れる必要があります。 それはすべて、負荷の種類、使用されるファイルシステムなど、多くの要因に依存します。 多くは、ハードウェアコンポーネントに依存します：ドライブモデル、RAID / HBA / JBOD。



一般的に、アプリケーションがioprioを使用して特定のプロセスに優先順位を付ける場合、CFQ / BFQの方向でスケジューラを選択することは正当化されます。 ただし、常に負荷の種類とディスクサブシステム全体の構成から始める価値があります。 一部のソリューションでは、開発者は非常に具体的な推奨事項を提示します。たとえば、クリックハウスでは 、HDDにはCFQを、SSDドライブにはnoopを使用することをお勧めします。 ドライブがより多くの帯域幅を必要とする場合、より多くのI / Oと平均遅延を実行する能力は重要ではありません。次に、BFQ / CFQの方向を確認する必要があります。ssdドライブもnoopおよびnoneです。



遅延を減らす必要があり、各操作、特に読み取り操作をできるだけ早く実行する必要がある場合は、ssdの使用に加えて、このために特別に設計されたデッドラインスケジューラ、または新しいものの1つであるmq-deadline、kyberを使用する価値があります。



推奨事項は一般的な性質のものであり、すべての場合に適しているわけではありません。 プランナーを選択する際、私たちの意見では、次の点を考慮する必要があります。

1. ハードウェアコンポーネントは重要な役割を果たします。RAIDコントローラーが有線クエリスケジューリングアルゴリズムを使用している場合に状況が発生する可能性があります。この場合、noneまたはnoopスケジューラーの選択が正当化されます。
2. 負荷のタイプは非常に重要です。実験ではなく、「戦闘状態」では、アプリケーションが他の結果を示す場合があります。 テストに使用されるfioユーティリティは負荷を一定に保ちますが、実際には、アプリケーションがディスクに均一かつ絶えずアクセスすることはほとんどありません。 1分あたりの平均の実際のキュー項目数は1〜3の範囲にとどまることができますが、ピーク時には10〜13〜150の要求になります。 それはすべて負荷の種類に依存します。
3. ランダムデータブロックの書き込み/読み取りのみをテストしました。スケジューラを使用する場合、順序は重要です。 線形負荷を使用すると、スケジューラーが要求を適切にグループ化すると、多くの帯域幅を取得できます。
4. 各スケジューラには、追加で構成できるオプションがあります。 それらはすべて、プランナーのドキュメントに記載されています 。

気配りのある読者は、異なるコアを使用してHDDおよびSSD / NVMeドライブのスケジューラーをテストしていることに気付いているはずです。 実際、HDDを使用した4.12カーネルでのテスト中、BFQおよびmq-deadlineスケジューラーの動作はかなり奇妙に見えました。遅延は減少し、その後数分間非常に大きくなりました。 この動作は適切に見えず、4.13カーネルが登場したため、新しいカーネルのHDDでテストを実行することにしました。



スケジューラコードが変更される可能性があることを忘れないでください。 次のカーネルリリースでは、特定のスケジューラが負荷のパフォーマンスの低下を示したメカニズムは既に書き直されており、少なくともパフォーマンスは低下していません。



Linux I / Oスケジューラー機能の機能は複雑なトピックであり、1つの出版物の枠組み内で検討することはほとんど不可能です。 今後の記事でこのトピックに戻る予定です。 戦闘でプランナーをテストした経験がある場合は、コメントでそれを読んで喜んでいます。