5

Linux でプロセスが停止した理由を特定しようとしています。これは通信アプリケーションであり、かなりの負荷がかかる状態で実行されます。8 つの T1 スパンごとに個別のプロセスがあります。ときどき、プロセスの 1 つが非常に応答しなくなります。通常は非常にビジーなプロセスのログにイベントが記録されるまでに、最大 50 秒かかります。

システム リソースが不足している可能性があります。明らかなこと - CPU 使用率 - は問題ないようです。

この種のものをキャッチして分析するのに最適なLinuxユーティリティはどれですか?これは非常に負荷の高いシステムであるため、できるだけ目立たないようにしますか? システム指向ではなく、プロセスである必要があるように思われます。おそらく /proc/pid/XX の継続的な監視ですか? ここでは Top はあまり役に立たないようです。

4

3 に答える 3

8

この「無応答の瞬間」を見つけることができる場合は、strace を使用して、その間に問題のプロセスにアタッチし、「スリープ」している場所を見つけようとすることができます。

strace -f -o LOG -p <pid>

より軽量ですが、信頼性の低い方法:

  1. プロセスがハングしたら、top/ps/gdp/strace/ltrace を使用してプロセスの状態を調べます (たとえば、「select」で待機しているか、ライブラリ呼び出しで 100% の CPU を消費しているかなど)。

  2. 問題の呼び出しの一般的な性質を把握して、strace の呼び出しを調整して、特定の syscall または syscall のグループをログに記録します。たとえば、ファイル アクセスに関連するシステムコールのみをログに記録するには、次を使用します。

    strace -e file -f -o LOG ....

strace がツールとして重すぎる場合は、監視してみてください。

  1. 「vmstat 1 > /some/log」でのメモリ使用量 - その間、プロセスがスワップイン (またはスワップアウト) されている可能性があります

  2. vmstat/iotop での IO 使用量 - 他のプロセスがディスクをスラッシングしている可能性があります

  3. /proc/interrupts - T1 カードのドライバーに問題が発生している可能性がありますか?

于 2008-10-21T21:34:53.373 に答える
2

問題のプログラムをトレースして、どのようなシステム コールが行われているかを確認できます。

于 2008-10-21T20:25:37.613 に答える
0

ありがとう-straceは便利に聞こえます。適切なタイミングでプロセスをキャッチすることは、楽しみの一部になります。定期的にタイムスタンプを共有メモリに書き込んでから、別のプロセスで監視するスキームを思いつきました。SIGSTOPを送信すると、少なくともgdbを使用してアプリケーションスタックを調べることができます。一時停止したプロセスのstraceが多くのことを教えてくれるかどうかはわかりませんが、straceをオンにして、それが何を言うかを確認することはできます。または、straceをオンにして、SIGCONTでプロセスをヒットします。

于 2008-10-21T22:04:50.503 に答える