Linux CPUスケジューラがプロセスを実行できる時間を長くすることはできますか？どうすればいいですか？
背景知識
この質問は、カーネルが同じCPUで実行される異なるプロセス間で強制的に切り替える頻度を減らす方法を尋ねます。これは、「プリエンプティブマルチタスク」と呼ばれるカーネル機能です。この機能は、1 つのプロセスが CPU を過度に使用してシステムが完全に応答しなくなるのを防ぐため、一般的に優れています。ただし、プロセス間の切り替え費用があるしたがって、トレードオフが必要です。
あるプロセスが取得できるすべてのCPU時間を使用している場合、他のプロセスがユーザーと対話している間に頻繁に切り替えると、遅延応答が減少する可能性があります。
取得できるすべてのCPU時間を使用する2つのプロセスがある場合は、移行頻度を下げると同じ時間にさらに多くの作業を実行できます。
やる気
この質問に対する私の最初の反応に基づいてこの記事を投稿します。 Linuxコンテキスト切り替え頻度を変更するには？
個人的に私は時間分割を変更したくありません。しかし、私はこれがCONFIG_HZビルドタイムオプションを持っていることを漠然と覚えています。だから今はどんな状況なのか気になりますね。 CPUスケジューラの時間分割はまだベースですかCONFIG_HZ？
さらに、実際にはビルド時間の調整は非常に限られています。 Linuxディストリビューションでは、CPUアーキテクチャごとに1つのコアを持ち、実行時または少なくとも起動時に構成できるようにすることがより実用的です。タイムスライスの調整がまだ関連している場合、ビルド時にタイムスライスをロックしない新しい方法はありますか？
ベストアンサー1
ほとんどのRHEL7サーバーでは、RedHatはsched_min_granularity_ns10msとsched_wakeup_granularity_ns15msに増やすことをお勧めします。 （源泉。技術的には、リンクは10μsと言われており、これは1000倍小さくなります。これは間違いです。）
私たちはこの提案をよりよく理解しようとすることができます。
sched_min_grainarity_nsの増加
現在のLinuxカーネルでは、CPUタイムスライスはCompletely Fair Scheduler（CFS）によってジョブに割り当てられています。sysctlCFSを調整するために使用できるいくつかの設定があります。
kernel.sched_min_granularity_nskernel.sched_latency_nskernel.sched_wakeup_granularity_ns
次の再起動までsysctlを一時的に設定するか、起動するたびに適用される設定ファイルに永続的に設定できます。これらの設定を適用する方法については、「sysctl」を探すか、短い紹介を読んでください。ここ。
sched_min_granularity_ns最も目立つ設定です。オリジナルでは計画設計 - CFS.txtこれは、「スケジューラを「デスクトップ」（低レイテンシ）から「サーバー」（良好なバッチ）ワークロードに調整する唯一の「調整可能」設定として説明されます。
つまり、この設定を変更してコンテキスト切り替えのオーバーヘッドを減らし、応答性（「待ち時間」）を犠牲にしてスループットを増やすことができます。
私の考えでは、このCFS設定は以前のビルドタイム設定を模倣したようです。構成_HZ。 CFSコードの最初のバージョンでは、デフォルトは1ミリ秒で、これは「デスクトップ」で使用されている1000Hzに相当します。 CONFIG_HZその他サポートされている値は250Hz（デフォルト）、「サーバー」側では100Hzです。 100Hzは非常に遅いCPUでLinuxを実行するときにも便利です。これが与えられた理由の1つです。CONFIG_HZがX86のビルド設定として最初に追加されたとき。
この値を10ms（つまり100Hz）に変更して測定してみると合理的なようです。 sysctlは次に測定されることを覚えておいてください。ナノ秒。 1ミリ秒= 1,000,000ナノ秒。
私たちは、これらの「サーバー」の時代遅れの調整が、一部の高負荷ベンチマークのスループットに関して2011年に依然として非常に関連していることがわかります。https://events.static.linuxfound.org/slides/2011/linuxcon/lcna2011_rajan.pdf
たぶん他の設定があるかもしれません。
上記の3つの設定のデフォルト値は比較的近いようです。これにより、私は物事を単純に保ち、すべてに同じ要素を掛けたいと思います:-).しかし、これについて調査した結果、スループットを調整しているので、より具体的な調整も関連性があるようです。
sched_wakeup_granularity_ns「ウェイクプリエンプション」が含まれます。つまり、イベントによってアクティブ化されたジョブが現在実行中のプロセスを即座にプリエンプトできるタイミングを制御します。 2011スライドは、この設定のパフォーマンスの違いも示しています。
このトピックの「WAKEUP_PREEMPTを無効にする」も参照してください。2010年IBM表彰これは、「一部のワークロードの場合」デフォルトで有効になっているこの機能が「CPU使用率の数パーセントポイントを消費できる」ことを意味します。
SUSE Linuxには、この値を半分より大きく設定するとsched_latency_nsウェイクプリエンプションを効果的に無効にし、「短いデューティサイクル操作はCPUホグと効果的に競合できなくなる」と提案する文書があります。
SUSEのドキュメントでは、他の設定のより詳細な説明も提案しています。ただし、自分のシステムで現在のデフォルト値が何であるかを確認する必要があります。たとえば、私のシステムのデフォルト値はSUSEのマニュアルに記載されているものとは少し異なるようです。
https://www.suse.com/documentation/opensuse121/book_tuning/data/sec_tuning_taskscheduler_cfs.html
これらのスケジューリング変数の1つを使用しようとすると、3つの変数すべてがCPUの数の1 + log_2だけ拡張（乗算）されることに注意する必要があると思います。このサイズ変更はを使用して無効にできますkernel.sched_tunable_scaling。何か落ちたかもしれませんが、これは素晴らしいようです。たとえば、インタラクティブなアプリケーションを提供し、全体/ほぼ完全な負荷で実行されているサーバーの応答性と、その応答性が各サーバーによってどのように拡張されるかを考える場合は、数値によって異なります。 CPUの。
ワークロードにスレッド/プロセス数が多い場合の推奨事項
また、他の設定では、ワークロードにスレッド数が多ければかなりのスループットが得られるという2013年の提案に触れました。 （またはより正確には、CFS以前のコアで達成されたスループットを再取得します。）
- 」2つの必須カーネル調整" - PostgreSQLメーリングリストに関する議論です。
- 」仮想ホスト構成ファイルで kernel.sched_migration_cost を増やします。" - Red Hatのバグ969491。
無視するCONFIG_HZ
CONFIG_HZ何を設定したのか心配する必要はないと思います。私の理解は、合理的なタイマーハードウェアがあると仮定すると、現在のコアとは無関係であるということです。また、見ることができますコミット 8f4d37ec073c, "sched: 高解像度プリエンプションが確認済み"、変更についてのスレッドのこのコメントを通して見つけることができます。https://lwn.net/Articles/549754/。
（コミットを見ると、それに応じて心配することはありませんSCHED_HRTICK。X86最近、いくつかのコミットでは要件が削除されたようです。）