Linux:
Linux カーネルにはこの問題に対する優れた実装があり、(CPU ガバナー、sysctl、または cgroup を介して) 実行中のプロセスのリソースを管理することを目的とした多くの機能/設定があります。基本的に、デフォルトの機能モードをアプライアンスに適応させます。
変更を適用した後のベンチマーク、ストレス テスト、および状況分析は、特に運用サーバーでは必須です。カーネル設定が必要な使用法に合わせて調整されている場合、パフォーマンスの向上は非常に重要になる可能性があります。一方で、これにはテストと、管理者にとって時間がかかるさまざまな設定の十分な理解が必要です。
Linux はガバナーを使用して、実行中のアプリケーション間で CPU リソースの負荷を分散します。多くのガバナーが利用可能です。ディストリビューションのカーネルによっては、一部のガバナーが利用できない場合があります (カーネルを再構築して、不足しているガバナーまたはアップストリーム以外のガバナーを追加することができます)。現在のガバナーを確認して変更し、さらに重要なことに、この場合はその設定を調整できます。
追加のドキュメント:読書、ガイド、同様の質問、周波数スケーリング、ガバナーの選択、パフォーマンス ガバナー、および cpufreq。
SysCtl:
Sysctl は実行時にカーネル パラメータを調べて変更するためのツールです。設定ファイル /etc/sysctl.conf を使用して調整を永続的に行うことができます。 多くのカーネル設定は Sysctl で変更できるため、これはこの回答の重要な部分です。使用可能な設定の完全なリストは、コマンド sysctl -a で表示できます。 、詳細はこちらとこちらの記事にあります。
グループ:
カーネルは機能を提供します:このガイドでは短い名前の cgroup で呼ばれる制御グループです。 cgroup を使用すると、CPU 時間、システム メモリ、ネットワーク帯域幅、またはこれらのリソースの組み合わせなどのリソースを、システムで実行されているタスク (プロセス) のユーザー定義グループ間で割り当てることができます。設定した cgroup を監視したり、特定のリソースへの cgroup のアクセスを拒否したり、実行中のシステムで cgroup を動的に再設定したりすることもできます。 cgconfig (グループ構成の制御) サービスは、起動時に起動し、事前定義された cgroup を再確立するように構成できるため、再起動後も永続化されます。
この件に関する情報源、参考資料、質問。
ラム:
これは、システムの RAM の量が限られている場合に役立ちます。それ以外の場合は、スワップを無効にして主に RAM を使用することができます。スワップ システムは、プロセスごとに、または swappiness 設定で調整できます。必要に応じて、プロセスごとにリソース (RAM) を ulimit で制限できます (他のリソースを制限するためにも使用されます)。
ディスク:
ディスク I/O 設定 (I/O スケジューラ) は、クラスタ サイズと同様に変更される場合があります。
代替案:
代わりに、nice、cpulimit、cpuset、taskset、ulimit などのツールを使用できます。
これに対する最良の答えは、「試してみてください」です...いくつかのストレステストを実行し、何が最良の結果をもたらすかを確認してください.これは、スレッドの動作のわずかなニュアンスがパフォーマンスの違いを引き起こす可能性があるためです。
以下は主に私自身の経験に基づいています...
どこから始めますか?
スレッドが枯渇するのを防ぐ Linux の機能はかなり優れています。すべてのスレッドが均等に分配されるとは限りませんが、すべてのスレッドが少なくともいくらかのパイを獲得します。 2 つのスレッドが CPU 時間を競合している場合... 1 つが 100% の CPU を使用しようとしていて、別のスレッドが 10% しか使用しようとしていないとしましょう... 91% と 9% またはどこかでバランスが取れていても驚かないでください。
特定のリソースが重い場合、全体的なパフォーマンスが低下する可能性があります オーバーサブスクライブ。これは、回転するハード ディスク上のディスク IO に特に当てはまります。ヘッドは、ディスク上の場所と 継続 の間を物理的に移動 (シーク) する必要があります 異なるファイル間で振動すると、大幅な速度低下が発生する可能性があります。ただし、1 つのスレッドが IO バウンドが多く、別のスレッドが少しでも 処理したい場合、この影響はかなり小さいことがよくあります。 IO.
これら 2 つのことを合わせると、多くの場合、20% のサブスクライブよりも 20% のオーバーサブスクライブの方が良いということになります。つまり、あまり CPU を使用しようとしないスレッドに CPU 時間を予約しないでください。
例:CPU にバインドされたスレッドがあり、ディスク IO にバインドされたスレッドがあり、8 つのコアと 1 つのハード ディスクがある場合、開始 8 つの CPU バウンド スレッドと 1 つのハード ディスク IO バウンド スレッド。 7 と 1 では、ほとんどの場合、コアがアイドル状態のままになる可能性があります。 8 と 1 はほぼ確実に HD スレッドを枯渇させません。つまり、HD と CPU の両方を完全に使用できます。
短命スレッドの危険性
Linux は 多く 苦労する可能性があることに注意してください。 寿命の短いスレッドの。これは、システムに損傷を与えようとする意図的な試みでより明白になります。しかし、継続的にスレッドやプロセスを生成すると、Linux の動作が悪くなる可能性があります。
あなたの質問では、長寿命のスレッドのように聞こえる専用のワーカー スレッドについて説明しました。これは正しいアプローチのように思えます。
ロンドンバス効果
バスを 30 分待った後、一度に 5 台のバスがやってきます。 これは、前のバスに乗る乗客が速度を落とすために発生します。後発のバスは乗客がいないためスピードが増し、束ねる効果が生じます。
同じ問題がスレッド化にも存在する可能性があり、特にスレッドがリソースをめぐって競合している場合に顕著です。あるディスクから読み取ってから別のディスクに書き込むなど、タスク間で予測どおりにスレッドが交互に実行される場合、期待どおりに確率的に分散するのではなく、スレッドがまとまる傾向があります。そのため、あるリソースが別のリソースの使用を遅くする可能性があります。このため、スレッドのタスクをさらに細分化した方がよい場合もあります。
cgroups
あまり詳しくは避けます。ただし、Linux には「cgroups」と呼ばれる機能があり、プロセスをグループ化し、それらの集合的リソースを制限することができます。これは、さらにパフォーマンスを調整する際に非常に役立ちます。
それらについての簡単な議論がここにあります。しかし、長い目で見れば役立つかもしれないので、Google に少し時間を費やしてその機能をすべて確認することをお勧めします。