5

修理済み：

うーん、これは少しばかげているようです。top が正しく表示されていないことが判明し、プログラムは実際には引き続き実行されます。CPU 時間が大きくなりすぎて表示できなくなったのではないでしょうか。いずれにせよ、プログラムは正常に動作しているようで、この質問全体は意味がありませんでした。

ありがとう（そしてばかげた質問でごめんなさい）。

元の質問:

Ubuntu サーバー 10.04.3 を実行しているコンピューターでシミュレーションを実行しています。短い実行 (<24 時間) は正常に実行されますが、長い実行は最終的に失速します。ストールとは、プログラムが CPU 時間を取得できなくなったものの、すべての情報をメモリ内に保持していることを意味します。これらのシミュレーションを実行するために、プログラムを SSH および nohup し、出力をファイルにパイプします。

その他の情報:

システムの RAM が不足しているわけではありません。プログラムは、完了するまでハード ドライブの読み取りまたは書き込みを行う必要はありません。計算は完全にメモリ内で行われます。停止後も PID があるため、プログラムは強制終了されません。私はopenmpを使用していますが、プロセスの最大数を増やし、最大時間は無制限です。ARPACK fortran ライブラリを使用して、行列の最大固有値を見つけています。

この動作の原因や、現在停止しているプログラムを再開する方法について何か考えはありますか?

ありがとう

4

3 に答える 3

4

これはあなたのタグからの OpenMP プログラムだと思いますが、実際にこれを述べたことはありません。ARPACK はスレッドセーフですか?

デッドロックに陥っているように思えます (MPI プログラムでは OpenMP よりも一般的ですが、確実に可能です)。最初に行うことは、デバッグ フラグをオンにしてコンパイルすることです。次にこの問題を見つけたときに、デバッガーをアタッチして、さまざまなスレッドが何をしているかを調べます。たとえば、gdb の場合、スレッドを切り替えるためのいくつかの手順がここに示されています。

于 2011-10-16T16:59:57.510 に答える
2

次にプログラムが「停止」したときは、GDB を接続してthread apply all where.

  • 一部のミューテックスを待機してすべてのスレッドがブロックされている場合は、デッドロックが発生しています。
  • 他の何か (読み取りなど) を待っている場合は、操作の完了を妨げている原因を突き止める必要があります。

通常、UNIX では、意味のあるスタック トレースを取得するために、デバッグ フラグをオンにして再構築する必要はありません。ファイル/行番号は取得できませんが、問題の診断には必要ない場合があります。

于 2011-10-16T17:26:37.557 に答える
1

実行中のプログラム (つまり、プロセス) が何をしているかを理解する方法として考えられるのは、デバッガーをプログラムにアタッチすることですgdb program *pid*(プログラムが でデバッグを有効にしてコンパイルされている場合にのみ有効-gです)。を使用してstrace -p *pid*。このコマンドは、プログラムまたはプロセスによって実行されたすべてのシステム コールを表示straceするユーティリティ (技術的には、システム コール インターフェイスの上に構築された特殊なデバッガ) です。ptrace

ltrace動的ライブラリ内の関数への呼び出しをインターセプトするというバリアントもあります。

それを感じるために、例えば試してみてくださいstrace ls

もちろん、strace実行中のプログラムがシステム コールを実行していない場合は、あまり役に立ちません。

よろしく。 バジル・スタリンケビッチ

于 2011-10-16T19:36:44.130 に答える