2016-05-24 19 views
2

kurento.conf.jsonファイルに記載されているさまざまなパラメータを説明してください。オブジェクトの作成が "exceptionLimit": "0.8"をしようとしているが、私はこのパラメータが設定ファイルにコメントされて見たときに例外を上げるためkurento.conf.jsonファイルのパラメータを理解

  • リソースの使用制限、それはコメントしているか、我々はそれを使用してはならない理由は何らかの理由があります?何のオブジェクトも、このパラメータはコメント化されて"killLimit": "0.7" 生きていないサーバーを再起動するための

  • リソースの使用制限、それは変更を行い、このパラメータかどうかを使用することをお勧めしているのですか?

  • "garbageCollectorPeriod": 240この値を240から10-20秒に変更すると、パフォーマンス上の問題はありますか?

  • "threads": 10これらのスレッドは着信接続を処理する責任があるため、このスレッド数をいくつかのより高い値に増やすか、深刻なCPU使用率を作成することをお勧めしますか?

P.S:私はスレッドカウントとガベージコレクションの数を微調整しようとしているが、私はオブザーバーあまり変化がなかった、それは私がKMSへの負荷を生成することができませんでした場合であるかもしれないかもしれません。

答えて

3

、いくつかのparamsは、ちょうど彼らが存在しており、使用することができます表示するようにコメントし、その他はデフォルト値を表示するために存在しています。それらのコメントを解除して、それらをアクティブにすることができます。

  • "exceptionLimit":サーバー負荷が80%の場合、メディアサーバーは例外を発生させます。この機能はデフォルトで有効になっており、デフォルト値を表示するためにここにキーがあります。
  • "killLimit":これは、メディア要素が存在しない場合にマシンの負荷をチェックする安全機能です。リソースが制限を超え、インスタンス化されたオブジェクトがない場合、メディアサーバーインスタンスは停止します。これは、オブジェクトが生きていないときにメディアサーバーがリソースを消費する状況がいくつかあったために導入されました。それは解決されましたが、機能はちょうど場合に備えて残されました。デフォルトではアクティブではありません。
  • "garbageCollectorPeriod":バインドされているWebSocketセッションが閉じられているときに、メディア要素がアクティブに保たれた秒数。これは、パイプラインを解放するのを忘れて、メディアサーバーに接続されているWebSocketが閉じている場合です。あなたがきちんとしていれば、ここで大きな違いは見られません。
  • "threads":リクエストに参加するスレッドの数。これは、多くのユーザーが同じ時間に部屋に参加し、同時にすべての新しいエンドポイントを要求するような極端な負荷状況では問題になります。ここに大きな影響を与える可能性は低いです。

これらのうちどれを変更しても大きな違いは見られませんが、非常に具体的なシナリオです。

+0

ありがとうございます。 –

+0

こんにちは、例外に達した時にexceptionLimitが発生し、例外が発生するとkmsサーバは停止しますか? –

+1

@SagarPilkhwalいいえ。メディアオブジェクトが作成されず、例外「NOT_ENOUGH_RESOURCES」が発生します。 – igracia

2
  • "exceptionLimit":デフォルト値がすでにある0.8ので、コメントしたり、値を変更しない場合、それは効果がありませんコメントを解除します。このパラメータは、新しいオブジェクトの作成中に例外が発生する前に使用可能なリソースの量を設定します。チェックされるリソースは、アプリケーションが持つ制限を使用してメモリとスレッドです。

  • "killLimit":これが設定に存在しない場合、この設定は無効です。設定されている場合、リソースが上限を超えている場合、すべてのオブジェクトが破棄されたときにメディアサーバーを終了します。これは、サーバがメモリやスレッドを漏らしていないことを確認するのに便利です。

  • "garbageCollectorPeriod":ここで設定する時間が短いほど、CPU消費量が高くなります。 CPU消費量が大幅に増加するだけでなく、他のアクションを遅らせる可能性のあるクリティカルな領域を取得します。私はこれを1分以内に決して決してしませんでした。

  • "threads":これはRPCを処理するスレッドです。メディアは独自のスレッドで処理されます。この数を増やすと、膨大な量のリクエストがなければ、何もしないでリクエストを待つスレッドプールを増やします。プロセス上に多くのスレッドを持つと、コンテキストが切り替わるためにパフォーマンスに影響を与える可能性があります。さらに、プロセスが使用できるスレッドの数は限られているため、スレッドを必要とせずにコントロールに費やすと、スレッドのソートによってメディアの一部が失われる可能性があります。 .conf.jsonファイルで

+0

ありがとうございました –

関連する問題