私は R を使用して多くの統計分析を行っており、AWS 上の大規模なマルチコアインスタンスを頻繁に利用しています。主にハイパーパラメータ検索、クロス検証、ブートストラップに使用します。
たとえば、コアを持つインスタンスと、一度にコアにファームされるレプリケートをc持つジョブがあるとします。現在、システム プロセス (実行中の ssh クライアントなど) により、レプリケート以外のジョブも実行されています。 r >= cchtopc
これは、オペレーティング システムの動作について私が理解している限りでは、何らかのプロセスがジョブをシャット オフして、htop(およびその他) がプロセッサにアクセスできるようにすることを意味します。これらのさまざまなプロセスにしばらく時間を与えると、ジョブが再開されます。
を見るとhtop、緑に赤がたくさん混ざっているのがわかります。緑は私の作品で、赤は私の作品を可能にするために作られた背景だと言っていいでしょうか?
直感的に、このようなシャッフルは最適ではないと思われます。そこで、私の直接の質問は、cコアにアクセスできる場合、複製ジョブをすべてのcコアに割り当てるべきでしょうか、それとも、あるいはc-1何か他の方法があるのでしょうか?
また、コンピューティング リソースがジョブに割り当てられる方法については、私が理解していないため、無視している詳細がたくさんあると思います。すべてのジョブがc-1コアに送られ、すべてのシステム プロセスがコアに送られるには、どのような処理が必要cthですか? 1 つのバーを除いて、すべての htop が緑色に変わりますか? また、これは意味がありますか?
ベンチマーク実験を行うことはできると思いますが、インスタンスやデータセットが膨大な場合は困難ですし、アプリケーション固有のものが多くあることを考えると、何を学べるかわかりません。そのため、仕組みをより深く理解したいと思っています。
答え1
実験せずに特定のアプリケーションにどのような影響があるかを正確に知ることは困難ですが、一般的な経験則として、コア数を少し超えることは有益ですが (たとえば、ほとんどのコンパイル ガイドでは、コア数/スレッド数 + 1 で make を呼び出すことを推奨しています)、大幅に超えると、余分なオーバーヘッドのために逆効果になる可能性があります。その理由は、タスクの 1 つ (またはいくつか) が I/O やタイマーなどを待機してスリープ状態になっている場合でも、他のスレッドは処理を続行できるためです。
作業のシャッフル (OS のスケジュール) は、すべての最新のオペレーティング システムで発生しており、これに対抗するのではなく、対処する必要があります。無関係な競合が発生していると思われる場合は、プロセスの nice レベルを下げることができますが、専用の AWS インスタンスでは... それが必要になるとは考えにくいです。