4

私のアプリケーションは基本的に、MMSイベントをルーティングするコンテンツベースのルーターです。

私が使用しているロガーは、SASLモードのOTPフレームワークに付属しているロガー「error_logger」です。

問題は::

クライアントを使用して、デフォルト値でMMSイベントを生成しています。このクライアント（Java）には、複数のスレッドで大量のイベントを送信する機能があります

Erlang / OTPで書かれたルーターに10スレッドで100イベントを送信しています（各スレッドは10 MMSイベントを送信しています）。

問題は、ルーターがこのような高負荷を受信すると、ロガーがハングする、つまりログファイルの更新を停止することです。ただし、ルーターは引き続きイベントをルーティングできます。

私が思いついた結論は::

  1. このような高負荷のイベントを受信した場合のErlangでのスケジューリングの問題（イベントごとに個別のプロセス）。

  2. 非常にありそうもないデッドロック状態。

  3. イベントを順番に送信するのではなく、複数のスレッドでイベントを送信することが原因である可能性があります。しかし、ルーターは複数のサービスプロバイダーボックスに接続されると思うので、スレッドでイベントを送信することを考えました。

誰かが問題を解明するのにmwを助けることができますか？

4

2 に答える 2

2

Erlang のどのバージョンを使用していますか? R14A (R13B4 かな?) より前は、メッセージ キューに多くのメッセージが含まれているときに選択的受信を呼び出すと、パフォーマンスが低下しました。この動作は、大量のメッセージを受信するプロセス (error_logger標準的な例) で、負荷にほとんど対応していない場合、負荷の小さなスパイクによって処理コストが急上昇し、新しい処理としてそこにとどまる可能性があることを意味しました。プロセスが耐えられる以上のコストがかかりました。この問題は R14A で解決されています。

第二に、大量のイベント/呼び出し/ログをテキスト ロガーに送信しているのはなぜですか? たとえば、人間が判読できるログ ファイルへの出力用に文字列をフォーマットすると、バイナリを使用するよりもはるかにコストがかかりdisk_logます。ロギングのコストを削減することは役に立ちますが、ログの量を減らすことはさらに役に立ちます。これらのことをログに記録する必要がある理由を正確に調査し、別の (より安価な) 方法で記録できないかどうかを確認してください。

の問題はerror_logger、多くの場合、他の過負荷の問題の症状です。この問題が発生した場合は、すべてのプロセスのメッセージ キューのサイズを調べて、他の何かがバックアップされているかどうかを確認してください。次の erlang シェルコードが役立つ場合があります。

[ { P, element(2, process_info(P, message_queue_len)) } 
  || P <- erlang:processes(), is_process_alive(P) ]
于 2010-08-30T19:48:58.600 に答える
2

あなたはすでに良い答えを持っていますが、私は議論に追加します.

error_logger はデフォルトでディスクへのキャッシュされた書き込み操作を使用します。したがって、1 つの可能性として、負荷が低いときはこれに気付かないが、負荷が高いと、書き込みがしばらくの間キャッシュ内でスタックすることがあります。

余談ですが、複数のスレッドが Erlang の呼び出しを行っても問題はないはずです。

これをテストする別の方法は、独自のロガーを error_logger に追加して、何が起こるかを確認することです。おそらく、シェルまたは「高速」な何かに印刷します。

于 2010-09-01T06:52:09.760 に答える