dirty_ground_ratioに達した後のIO調整

dirty_ground_ratioに達した後のIO調整

Linux IO調整メカニズムを理解したいと思います。これが私が今まで得たものです:

write (fd, data, size)システムコールを呼び出すと、データはオペレーティングシステムキャッシュにダーティページとして書き込まれます。 OSにはダーティページを管理するdirty_background_ratio2つの割合があります。dirty_ratioダーティページが到着すると、オペレーティングシステムはバックグラウンドフラッシュを開始しますdirty_background_ratio。これはdirty_ratio、オペレーティングシステムの超過を防ぐ厳しい制限です。

ダーティページ数がdirty_background_ratio<無料実行)。ダーティページ数が制限を超えると、オペレーティングシステムはdirty_background_ratioバックグラウンドフラッシュを非同期的に実行し、ダーティページをクリーンアップします。しかし、私が正しい場合、set_point = (dirty_ratio + dirty_background_ratio) / 2私が理解したところによれば、OSはダーティ比を維持しようとしますset_pointうーん提出Linuxカーネル:

ユーザーは、グローバル(バックグラウンド+ダーティ)/ 2 = 15%のしきい値を超えると、アプリケーションが制限され、約17.5%にバランスが取れることがわかります。

これを実際にテストするために、書き込みブロックから65 GBIOデータを生成する(システムコールを使用して)Cで簡単なアプリケーションを実装しました。同時に、帯域幅(処理量、タイムアウト)、ダーティページ数を測定し、ダーティページ数を次に分割します。1 GBwritedirtyable memory = free memory + reclaimable + file cacheグローバルダーティメモリ)。

マイシステム(CPU:Xeon 6138、RAM:)は、カーネルバージョンの192 GBCentOS Linux 7(Core)を実行します3.10.0-862.9.1.el7.x86_64。 IOターゲットは400 MB/s書き込み帯域幅を持つSSDデバイスです。実験する前に電話しました。同期コマンドを実行し、古いダーティページがすべてフラッシュされるのを待ちます(最初から、グローバルダーティページの割合がほぼゼロであることがわかります)。実験はきれいな状態でシステムで行われました(汚れたり高価なプロセスはなく、システムで実行されているOS管理関連プロセスのみがあります)。私の測定値は次のとおりです。

IOスループット/ダーティページ

これx軸表示済みn番目データ投入1 GB。測定された結果は、計算された比率と非常によく一致します(、、、dirty_background_ratio = 10%)。ただし、実験を実行するたびに(他のストレージデバイスでも)リーチが表示されます。グラフの赤い領域でこれを見ることができます。上記のように、さまざまな情報源から読み取った内容に基づいてset_point = 15%balanced around 17.5%dirty_background_ratioうーん)、制限に達するまで制限は発生しないでくださいset_point。代わりに、調整が開始されると、調整は急速に増加し、ディスク書き込み帯域幅(同期性能)に収束する点dirty_background_ratioに達するまで安定して保持されます。set_point400 MB/s

私の質問は次のとおりです。set_point(赤い領域)に達する前にIO制限に達するのはなぜですか?オペレーティングシステムで調整の程度を決定する方法今後達成するset_point


私はしばらく前にこの質問をしました。ユーザー495217は、これがオペレーティングシステムのバックグラウンドアクティビティによる副作用である可能性があるとコメントしました。これが本当かと思います。それでは、これについて議論したリソースを知っている人はいますか?それとも、これを実証する実験を行うことを提案した人はいますか? IO中にCPU命令の数と1秒あたりのサイクル数を測定しましたが、それを証明できる変化は観察されませんでした。

ベストアンサー1

おすすめ記事