web-dev-qa-db-ja.com

100％CPUを使用したirssiのデバッグ

私はDebianを持っていますVM ESX4.0サーバーで実行しています。これVMは多数のユーザーをホストし、それぞれが画面内でirssiセッションを実行していますインスタンス。

これは、1人のユーザーを除いて、非常にうまく機能しています。何らかの理由で、このirssiセッションは100％のCPU使用率でピークに達し続けます（正常に動作し続けます）。より正常に動作している他のirssiセッションにロードされていないスクリプトは実行されていません。

100％CPUはすぐには起動しませんが、通常は起動後数時間以内に起動します。それは決して消えません。

この問題の原因をどのようにデバッグしますか？ straceを使用してみましたが、開始時とピーク後の呼び出しには確かに異なるパターンがありますが、すぐには何もわかりませんでした。

開始時に、30秒以上の通話のヒストグラムを次に示します。

time: 334
gettimeofday: 317
poll: 122
read: 9
write: 2
restart_syscall: 1

CPUがペギングを開始すると、次のようになります。

gettimeofday: 230176
read: 115122
poll: 115106
time: 531
write: 107
waitpid: 38
_llseek: 2
ioctl: 2
fstat64: 2
open: 2
close: 2
fcntl64: 2
unlink: 1

ペギングプロセスの「ltrace-S」のヒストグラムは、これらを上位のエントリとして示しています。

SYS_read: 61731
g_io_channel_read: 34115
SYS_gettimeofday: 24662
SYS_poll: 12344
fflush: 6828
g_main_context_iteration: 6823
__ctype_toupper_loc: 4025
g_strcasecmp: 3757
g_hash_table_lookup_extended: 3325
g_direct_hash: 3068

何が足りないのですか？これを解決するための次のステップは何ですか？

debianvmware-esxstrace
4
zigdon

Read（）とpoll（）が何であるかを理解する必要があると思います。新しいファイルを常に開いたり閉じたりするわけではないので（明らかに、30秒ごとに2つだけ）、lsofはそれを通知する必要があります。

ここのように、パイプからread（）している場合：

COMMAND    PID       USER   FD      TYPE             DEVICE     SIZE   NODE NAME
irssi     4993       user    5w     FIFO                0,6         2941908 pipe

次に、出力内の名前付きパイプの名前または名前なしパイプのノード番号のいずれかであるパイプのすべてのプロセスとgrepに対してrootとしてlsofを実行します。 （この場合、2941908です。）これにより、irssiと、パイプの反対側にあるプロセスが表示されます。

パイプにもう一方の端がない場合…ええと、わかりません。たぶん、開始から問題が発生するまでのプロセスの1つを追跡し、パイプで何が起こっているのかを理解します。 '-e trace ='フラグを使用して出力をstraceに制限することは理にかなっているかもしれませんが、頭のてっぺんから制限するための適切なセットを考えることはできません。

1
wfaulk