Linuxカーネルには、Noop IOスケジューラー、Anticipatory IOスケジューラー、Deadline IOスケジューラー、CFQ IOスケジューラーの4つのIOスケジューラーが含まれています。
予期的、予想、早期に発生、予想
通常、ディスクの読み取りと書き込みの影響は、ヘッドのシリンダーへの移動によって引き起こされます。この遅延を解決するために、カーネルは主に、キャッシュとIOスケジューリングアルゴリズムを使用して補正します。
この記事は簡単な紹介です。
スケジューリングアルゴリズムの概念
データブロックをデバイスに書き込んだり、デバイスからデータブロックを読み取ったりすると、要求はキューに入れられ、完了を待機します。
各ブロックデバイスには独自のキューがあります。
I / Oスケジューラは、これらのキューの順序を維持してメディアをより効率的に使用する役割を果たします。I/ Oスケジューラは、順不同のI / O操作を順序付けられたI / O操作に変換します。
カーネルは、スケジューリングする前に、キューにある要求の数を最初に決定する必要があります。
IOスケジューラー(IOスケジューラー)
IOスケジューラー(IOスケジューラー)は、オペレーティングシステムがブロックデバイスでIO操作が送信される順序を決定するために使用される方法です。2つの目的があります。1つはIOスループットを改善することであり、もう1つはIO応答時間を短縮することです。ただし、IOスループットとIO応答時間は相反する場合が多く、2つをバランスさせるために、IOスケジューラは複数のスケジューリングアルゴリズムを提供して、さまざまなIO要求シナリオに適応します。その中で、データベースのランダムな読み取りと書き込みのシナリオで最も有利なアルゴリズムは、DEANLINEです。
カーネルスタック内のIOスケジューラの場所は次のとおりです。
ブロックデバイスの最も悲劇的な部分はディスクの回転です。このプロセスには非常に時間がかかります。
各ブロックデバイスまたはブロックデバイスパーティションには独自のリクエストキュー(request_queue)があり、各リクエストキューはI / Oスケジューラを選択して、送信されたリクエストを調整できます。I / Oスケジューラの基本的な目的は、ブロックデバイス上の対応するセクター番号に従って要求を配置し、磁気ヘッドの動きを減らして効率を向上させることです。各デバイスのリクエストキューにあるリクエストに順番に応答します。実際、このキューに加えて、各スケジューラは、送信されたリクエストを処理するために異なる数のキューを維持し、キューの最上部にあるリクエストは、応答を待つ時間内にリクエストキューに移動されます。
IOスケジューラの役割は、主にディスクローテーションの必要性を減らすことです。主に2つの方法で達成されます:
1.マージ
2.ソート
各デバイスは独自の要求キューに対応し、すべての要求は処理される前に要求キューに置かれます。新しいリクエストが届いたときに、このリクエストが前のリクエストに隣接していることが判明した場合は、1つのリクエストにマージできます。マージが見つからない場合は、ディスクの回転方向に従ってソートされます。通常、IOスケジューラの役割はマージとソートですが、単一のリクエストの処理時間にはあまり影響しません。
1、NOOP
noopと
は何ですか?noop は入出力スケジューリングアルゴリズムです。NOOP、操作なし。何もせず、1つずつ処理するように要求します。このアプローチは、実際にはよりシンプルで効果的です。問題は、従来のディスクでは受け入れられないほど多くのディスクシークがあることです。しかし、SSDディスクの場合、SSDディスクを回転する必要がないため、そうすることができます。Noopは
、エレベータースケジューリングアルゴリズムとしても知られています。noopの原則とは何ですか?
入出力要求をFIFOキューに入れ、次にキュー内の入出力要求を順番に実行します。
新しいリクエストが来たとき:
- マージできるなら、マージ
- マージできない場合は、ソートを試みます。キュー上の要求がすでに非常に古い場合、この新しい要求はキューに入れることができず、最後にのみ置くことができます。それ以外の場合は、適切な位置に挿入します
- マージできず、挿入する適切な場所がない場合は、要求キューの最後に配置されます。
- 該当するシーン
4.1入出力要求のシーケンスを変更したくないシナリオの場合;
4.2 NASストレージデバイスなどの入出力でよりインテリジェントなスケジューリングアルゴリズムを備えたデバイス;
4.3上位層のアプリケーションによって慎重に最適化された入出力要求;
4.4非回転ヘッドSSDディスクなどのディスクデバイス
2. CFQ(完全に公平なキューイング)
CFQ(Completely Fair Queuing)アルゴリズムは、その名前が示すように、完全に公正なアルゴリズムです。これは、競争権が割り当てられて使用するすべてのブロックデバイスを処理しようとする请求队列
と时间片
、プロセスに割り当てられたタイムスライスのスケジューラは、プロセスを読み取ることができ、基礎となるブロックデバイスへの書き込み要求、プロセスのタイムスライスが消費され、プロセスを要求キューは一時停止され、スケジューリングを待機します。
各プロセスのタイムスライスと各プロセスのキューの長さは、プロセスのIO優先度に依存します。各プロセスにはIO優先度があります。CFQスケジューラは、プロセスのIO優先度を考慮事項の1つとして使用して、プロセスのIO優先度を決定しますリクエストキューがブロックデバイスを使用する権利を取得できる場合。
高から低へのIO優先度は3つのカテゴリに分類できます。
RT(リアルタイム)
BE(ベストトライ)
IDLE(アイドル)
それらの中で、RTとBEはさらに8つのサブ優先順位に分類できます。ioniceで表示および変更できます。優先度が高いほど、処理が早くなり、この処理に使用されるタイムスライスが多くなり、一度に処理される要求が多くなります。
実際、CFQスケジューラーの公平性はプロセスに対するものであり、同期要求(読み取りまたは同期書き込み)のみがプロセスに存在することはすでにわかっています。これらの要求はプロセスの要求キューに入れられ、すべて同じです。優先度の非同期リクエストは、どのプロセスからのものでも、パブリックキューに入れられます。非同期リクエストキューには、合計8(RT)+8(BE)+1(IDLE)= 17があります。
Linux 2.6.18以降、CFQはデフォルトのIOスケジューリングアルゴリズムです。汎用サーバーの場合、CFQがより良い選択です。使用するスケジューリングアルゴリズムは、ベンチマークとして選択する特定のビジネスシナリオによって異なります。他の人のテキストだけで決定することはできません。
3、締切
DEADLINEは、CFQに基づいてIO要求が枯渇するという極端なケースを解決します。
CFQ自体が持つIOソートキューに加えて、DEADLINEはさらに、それぞれ読み取りIOおよび書き込みIOのためのFIFOキューを提供します。
読み取りFIFOキューの最大待機時間は500ミリ秒、書き込みFIFOキューの最大待機時間は5秒です(もちろん、これらのパラメーターは手動で設定できます)。
FIFOキューのIO要求の優先度はCFQキューの優先度より高く、読み取りFIFOキューの優先度は書き込みFIFOキューの優先度より高くなっています。優先度は次のように表すことができます。
FIFO(読み取り)> FIFO(書き込み)> CFQ
デッドラインアルゴリズムは、特定のIO要求の最小遅延時間を保証しますこの観点から、DSSアプリケーションに適しているはずです。
締め切りは、実際にはElevatorの改善です:
1は、一部のリクエストが長時間処理されることを回避します。
2読み取り操作と書き込み操作を区別します。
締切IOは3つのキューを維持します。エレベーターと同様に、最初のキューは物理的な場所で可能な限り並べ替えられます。2番目のキューと3番目のキューは時間でソートされます。違いは、1つは読み取り操作で、もう1つは書き込み操作です。
デッドラインIOが読み取りと書き込みを区別するのは、アプリケーションが読み取り要求を送信すると、一般にそこでブロックされ、結果が返されるまで待機するとデザイナーが信じているためです。書き込み要求は通常、メモリに書き込むアプリケーション要求ではなく、バックグラウンドプロセスがそれをディスクに書き込みます。アプリケーションは通常、書き込みの完了を待たずにダウンし続けます。したがって、読み取り要求は書き込み要求よりも優先度が高くなければなりません。
この設計では、新しい各リクエストが最初のキューに最初に配置されます。アルゴリズムはエレベーターと同じで、読み取りまたは書き込みキューの最後に追加されます。このようにして、最初のキューからの一部のリクエストが最初に処理され、2番目/ 3番目のキューの最初のいくつかのリクエストの待機時間が長すぎるかどうか、しきい値を超えている場合は処理されます。このしきい値は、読み取り要求の場合は5ms、書き込み要求の場合は5sです。
個人的には、Oracleのオンラインログ、MySQLのbinlogなど、データベース変更ログを記録するパーティションについては、このパーティションを使用しないことが最善であると考えています。このタイプの書き込み要求は通常fsyncと呼ばれるためです。書き込みが完了していない場合、アプリケーションのパフォーマンスにも影響します。
4、期待
CFQおよびDEADLINEの考慮事項の焦点は、分散したIO要求を満たすことです。順次読み取りなどの継続的なIO要求の場合、最適化は行われません。
ランダムIOおよびシーケンシャルIOのシナリオを満たすために、LinuxはANTICIPATORYスケジューリングアルゴリズムもサポートしています。DEADLINEに基づいて、ANTICIPATORYは読み取りIOごとに6msの待機時間枠を設定しました。OSがこの6ミリ秒以内に隣接する場所から読み取りIO要求を受信すると、すぐに満たすことができます。
まとめ
IOスケジューラアルゴリズムの選択は、ハードウェアの特性とアプリケーションシナリオの両方に依存します。
従来のSASディスクでは、CFQ、DEADLINE、およびANTICIPATORYはすべて適切な選択肢であり、専用データベースサーバーの場合、DEADLINEのスループットと応答時間は適切です。ただし、SSDやFusion IOなどの新しいソリッドステートドライブでは、他の3つのアルゴリズムの最適化はシーク時間の短縮に基づいており、ソリッドステートドライブにはいわゆるシーク時間がなく、 IO応答時間が非常に短い。
ファンワイ
SUSE Linux Enterprise Server 11 SP1は、さまざまなI / O使用パターンを最適化するためのI / Oスケジューラーの代替案をいくつか提供します。ブート時にエレベーター=オプションを使用してI / Oデバイスのスケジューラーを設定するか、特定のI / Oスケジューラーを個々のブロックデバイスに割り当てることができます。
Completely Fair Queuing(CFQ)スケジューラ
Completely Fair Queuing(CFQ)スケジューラは、SUSE Linux Enterprise Server 11 SP1のデフォルトのI / Oスケジューラです。CFQスケジューラーは、スケーラブルなプロセスごとのI / Oキューを維持し、使用可能なI / O帯域幅をすべてのI / O要求間で均等に分散しようとします。I / O要求の負荷分散には、いくつかのCPUコストがあります。
締め切りスケジューラ
Deadlineスケジューラーは、CFQスケジューラーの代替手段の1つです。デッドラインスケジューラは、デッドラインアルゴリズムを使用して、I / Oリクエストの開始時間を保証することにより、I / Oレイテンシを最小限に抑えます。スケジューラは、複数のI / O要求の間で公平になり、プロセスの枯渇を回避しようとします。このスケジューラーは、I / Oパフォーマンスを改善するために、要求を積極的に並べ替えます。
NOOPスケジューラー
NOOPスケジューラーは、I / Oキューの管理に伴うCPU使用率のコストを最小限に抑えることができるもう1つの代替手段です。NOOPスケジューラは単純なFIFOキューで、I / O操作ごとに最小限のCPU /命令を使用して、I / O操作を完了するための基本的なマージおよびソート機能を実現します。
I / Oスケジューラーのテスト結果
このテストでは、システムBに接続されている23台の回転しているハードディスクが、メインデータベース領域用の52台の73 GB SAS SSDデバイスに置き換えられています。
表1は、すべてのワークロードを使用する3つの異なるI / Oスケジューラーとデータベースのパフォーマンスを比較しています。読み取り/書き込み混合のワークロード(2と4)では、NOOPスケジューラーがパフォーマンスに悪影響を及ぼすため、これらのワークロードには使用しないでください。Deadline I / Oスケジューラーは、パフォーマンスの低いストレージで小さなワークロードに対して実行すると、パフォーマンスの良いストレージで大きなワークロードに影響を与えずに、パフォーマンス上の利点を示します。
注意
次の表に示す値は、パフォーマンスメトリックの結果です。
I / Oスケジューラーの結論
このテストで使用されるワークロードについては、DeadlineスケジューラーがデフォルトのCFQスケジューラーよりも全体的に良い選択でした。小さなワークロードでより高いスループットが得られ、より大きなワークロードでCFQスケジューラと同等に実行されました。これらの特定のワークロードはデッドラインスケジューラで最高のパフォーマンスを発揮しましたが、すべてのワークロードが同じスケジューラから同じように恩恵を受けるわけではありません。最適なパフォーマンスが要件である場合、ワークロードに対する各I / Oスケジューラの利点を調査することは価値があります。
参考文献
https://www.bilibili.com/read/cv4365546
https://www.cnblogs.com/gomysql/p/3582185.html
https://www.cnblogs.com/cobbliu/p/5389556.html
https:/ /www.cnblogs.com/zhfan/archive/2013/06/08/3125856.html
https://www.ibm.com/support/knowledgecenter/en/linuxonibm/performance/tuneforsybase/ioschedulers.htm
Kotlin開発者コミュニティ
中国で最初のKotlin開発者コミュニティの公開アカウント。主にKotlinプログラミング言語、Spring Boot、Android、React.js / Node.js、関数型プログラミング、プログラミングのアイデアなどの関連トピックを共有および交換しています。
世界が騒々しいほど、より平和な思考が必要です。