読んでいたこのリンクちょうど今、考えさせられました。
少し前に、32 コアの VM の最大 30 コアでシミュレーションを起動していましたが、これはnohup perl ...<rest of command>...STOUT/STDERR を呼び出してリダイレクトするラッパー スクリプトを使用して実行していました。具体的な内容がそれほど重要かどうかはわかりませんので、詳細は省略します。
私はマルチスレッド タスク処理の概念には満足していますが、各プロセスを nohup 呼び出しでバックグラウンド処理すれば (各プロセスは数週間にわたって実行される個別のシミュレーションでした)、各子プロセスを独自のコア/スレッドに配置して、GNU Parallels などに頼ることなく完了まで処理を進めるのに十分であると単純に想定していました。
定期的にチェックしたところ、常に 30 個の vCPU がタスクを処理しており、すべてが妥当な時間内に完了していたため、これまでのところ私のロジックに問題はないようです...
誰かが（どこかの SO ページでそう思ったのですが）これが「CPU スラッシング」を引き起こす可能性があると言っていました。
私の質問には相互に関連する部分がいくつかあります。
- まず、nohup やバックグラウンド処理で特定のコアにプロセスを固定できると想定したのは間違っていたでしょうか? (また、特定のコアで実行されているプロセスをターミナルに表示できますか? 私の知る限り、top はどのコアがビジー状態であるかを示すだけで、どのタスクを実行しているかは示しません。)
- 次に、システムの他のタスクを処理するために使用できる予備の CPU が 2 つある場合でも、CPU スラッシングは発生しますか?
- 最後に、もし私が間違っていなければ、特定のプロセスは特定のCPUに固定されるのでしょうか？そしてそのCPUだけまたは、呼び出し順序やタイミングなどに応じてスレッド間を移動するのでしょうか。つまり、ファイルをループした場合、最初のファイルは CPU 0 に固定され、次に 1、2 と完了するまで固定されるのでしょうか。
答え1
まず、nohupやバックグラウンド処理は、特定のコアで実行されているプロセスをターミナルに表示するためのものだと私が想定していたのは間違っていたのでしょうか？私の知る限り、topはどのコアがビジー状態であるかを示すだけで、どのタスクを実行しているかは示さないのでしょうか？）特定のコアにプロセスを固定するのに十分でしょうか？（そして、
Nohup は、コマンドを nohup なしで実行した場合とまったく同じように実行します。唯一の違いは、終了時にシグナルを送信する pid のリストから削除されることです。(disown は、nohup で開始されていないプロセスに対して機能します)。
次に、システムの他のタスクを処理するために使用できる予備の CPU が 2 つある場合でも、CPU スラッシングは発生しますか?
nohup なしで CPU スラッシングが発生した場合のみ...
最後に、私が間違っていなければ、特定のプロセスは特定の CPU のみに固定されるのでしょうか、それとも呼び出し順序やタイミングなどに応じてスレッド間を移動するのでしょうか。つまり、ファイルをループした場合、最初のファイルは CPU 0 に固定され、次に 1、2 と完了するまで固定されるのでしょうか。
nohup なしの場合と同じです...
ps を使用すると、プロセスがどの CPU コア上で実行されているかを表示できます。また、taskset を使用してコアの制限を設定したり、制限を変更したりできます。
ps -eo pid,sgi_p,cmd --sort sgi_p
taskset -c -p 0 1234
答え2
nohup特定のコア上でプロセスを保持するための設定は何も行いません。通常はtasksetnohupそれに加えてtop、プロセスが最後にスケジュールされたコアを表示できますP。それが列です。
プロセスとスレッドのスケジューリングは、CPU アフィニティ、キャッシュ アフィニティ、割り込み処理、電力エンベロープなど、考慮すべき要素がますます増えているため、長年にわたって非常に複雑になっています。ただし、システムが他のタスクで忙しくない場合、使用可能なコア数よりも少ないジョブを開始すると、スラッシングが発生することは予想されません。同様に、タスクがどの CPU で実行されるかを実際に予測することはできませんが、適切であれば、スケジューラはコアを選択した後、そのコアでタスクを維持する可能性が非常に高くなります。