アスタリスク - 理由もなく非常に高い負荷平均

Question

わかりました。解決しました。これは単なる回避策ですが、問題は私にとって許容できるレベルまで減少しました。

日中に予期せぬ再起動が行われた後、負荷平均が大幅に低下していることに気付きました。サーバー監視システムを確認したところ、負荷平均は 3 ～ 4 時間連続して (かつ安定して) 負荷がかかっている間、常に少しずつ上昇していました。前日中に再起動できなかったため、これは目立ちませんでした。

前述したように、アプリケーション経由で呼び出される Perl スクリプトがいくつかありますAGI()。そのうちの 1 つはh拡張機能で呼び出され、単純な DB クエリを 1 つ実行するだけです。DB が少し過負荷になることがあることが判明しました。クエリは 200 ～ 500 ミリ秒待機する必要があり、Asterisk は Perl スクリプトが終了するまで待機する必要があります。

そこで、私はfork()最初に Perl スクリプトを変更し、AGI() 呼び出しが常に即時に返されるようにしました。これは非常に役立ちました。LA は大幅に安定しました。これは完全な解決策ではありません。Asterisk の内部でまだ何かが壊れているようですが、速度は大幅に低下し、ほとんど問題にはなりません。

すぐに使えるコードを探している人向け (fork()の前にすべての変数を取得することを忘れないでください。後でアクセスできなくなります$AGI):

my $AGI = new Asterisk::AGI;

# get all your variables here
my $var = $AGI->get_variable('var');

undef $AGI;

if (fork) { exit 0; };
open STDIN,  '<', '/dev/null'; # dont forget to free your parent's file handles
open STDOUT, '>', '/dev/null';
open STDERR, '>&STDOUT';

バグのようですが、私以外にこのような問題を抱えている人がいないのはなぜでしょうか。

編集1:AGI呼び出しをなくした後、問題は完全に解消しました。私は、非同期処理の情報を保存するカスタムODBC関数 ( ) をいくつか作成しただけです (これは後で別の Perl デーモンによって処理されます)。LA は 20 ～ 25 から 0.5 ～ 0.9 に低下しました (!)。これほど大きな負荷が発生するとはfunc_odbc.conf思いませんでした。AGI

Answer 1