SIP アプリケーションのトラブルシューティング

このトピックを使用し、SIP アプリケーションをトラブルシューティングすることができます。

このタスクについて

SIP アプリケーションに関する問題をトラブルシューティングするときに、以下の SIP コンテナーのトラブルシューティングの基本を使用します。

  • システムの平均 CPU 使用率は、60% から 70% の数値を超えないようにすべきです。
  • コンテナーは、割り振られた VM ヒープ・サイズの 70% を超えないように使用する必要があります。 システムに十分な物理メモリーがあり、VM ヒープ・サイズに対応できることを確認してください。 コール・ロードとセッション・タイムアウトは、ヒープ使用率に大きな影響を与えます。
  • コンテナーが稼働している VM の最大ガーベッジ・コレクション (GC) 時間は、 500 ミリ秒を超えてはなりません。またその平均は 400 ミリ秒未満でなければなりません。 冗長 GC を使用してこれを測定することができ、また PMI ビューアーを使用して GC 時間、ヒープ使用率、アクティブ・セッションなどをグラフィック形式で表示することができます。

手順

以下のトラブルシューティング・チェックリストを使用して、SIP アプリケーションに関する問題をトラブルシューティングします。
  • 構成の listen ポートを確認します。
  • netstat –an を使用して listen ポートを確認します。
  • 仮想ホストが定義されているかどうかを確認します。
  • ホスト別名が定義されているかどうかを確認します。
  • アプリケーションは、インストールされていますか。開始していますか。
  • プロキシー構成の場合、デフォルト・クラスターは構成されていますか。 プロキシーとサーバーがマシン上にある場合は、ポートが競合していませんか。

タスクの結果

問題が解決されない場合、以下の SIP コンテナーの症状および解決策を使用して、特定の症状をチェックします。
  • 症状: 再送信が多く、CPU 使用率が周期的にゼロに下がります。 または、ThreadPoolQueueIsFullException 例外がログに表示されます。

    ソリューション: これは、多くの場合、逆 DNS 検索に起因する DNS 問題で、 Ethereal のようなツールを使用して確認できます。ネットワーク・キャプチャーを行い、 IP アドレスを含む多数の DNS クエリーを送信し、応答でホスト名を取り戻す場合は、この問題が起こる可能性があります。 HP、またはネーム・サービス・キャッシングを必要とする他のプラットフォームの場合、nscd が実行中であることを確認します。 Microsoft Windows プラットフォームは、ネーム・サービス・キャッシングを必要としません。別のソリューションは、ホスト名を /etc/hosts ファイルに追加することです。

  • 症状: 再送信が多く、CPU 使用率が周期的に 100% に急上昇します。

    ソリューション: これは、多くの場合、ガーベッジ・コレクションによるもので、 冗長 GC (管理コンソールでアクセス可能) でチューニングし、 GC 周期の長さを調べることで確認できます。 ここでのソリューションは、JVM オプション引数を -Xgcpolicy:gencon に設定して、 世代別ガーベッジ・コレクションを使用可能にすることです。

  • 症状: 再送信が多く、CPU 使用率が長時間 100% に急上昇し、世代別ガーベッジ・コレクションは使用可能になっています。
    ソリューション: これは、多くの場合、SIP セッション・オブジェクトが長時間にわたり無効化されていないか、タイムアウトになっていないことに起因します。 ソリューションの 1 つとしては、アプリケーションの sip.xml にあるセッション・タイムアウト値を より小さな値に設定することです。これを処理する最も効率のよい方法は、 ダイアログが完了するときに (つまり、BYE を受信したら) アプリケーションがセッションの無効化を呼び出すことです。 SystemOut.log ファイルの次のエントリーは、 セッション・タイムアウト値がコンテナーにインストールされている各アプリケーション用であることを示しています。
    SipXMLParser  3 SipXMLParser getAppSessionTTL Setting Expiration time: 7 Minutes, For 	App: TCK back-to-back user agent”
    注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
  • 症状: 新規の INVITE メッセージを SIP コンテナーに送信するときに、 「480 サービスは使用できません」メッセージが数多くコンテナーから受信されました。 また、サーバーがこの状態のときに、しばしば SystemOut.log に「LoadManager E LoadManager warn.server.oveloaded」のメッセージが表示されます。

    ソリューション: これは、多くの場合、SIP コンテナーの構成可能メトリックの 1 つが超過していることに起因します。 これには、「最大アプリケーション・セッション数」の値と「最大メッセージ数/平均期間」の値が含まれています。 ソリューションは、これらの値を大きな値に調整することです。

  • 症状: 再送および呼び出しの多くは、SystemErr.log の OutOfMemory 例外が発生し、完了しません。

    ソリューション: これは、通常の場合、コンテナーに関連付けられている VM ヒープ・サイズが不足しており、増加しなければならないことを意味します。 この値は、管理コンソールから調整できます。

  • 症状: SIP 要求を SIP プロキシーへ送信したときに、「503 サービスを使用できません」を受信します。

    ソリューション: これは、通常の場合、プロキシーにセットアップされたデフォルト・クラスター (または、メッセージに一致するクラスター・ルーティング・ルール) がないことを意味します。 また、SIP プロキシーは正常に構成されているが、 バックエンド SIP コンテナーが停止されているか、異常終了した場合に、この症状が発生することもあります。

  • 症状: SIP 要求を SIP プロキシーへ送信したときに、「404 Not Found」を受信します。

    ソリューション: これは、通常の場合、デフォルト・クラスターに常駐するコンテナー用にセットアップされた仮想ホストがないことを意味します。 また、プロキシーのデフォルト・クラスターにあるサーバーに SIP アプリケーションが含まれていないか、 あるいは、デフォルト・クラスターにインストールされているアプリケーションの 1 つとメッセージが一致しないことを意味する場合もあります。

  • 症状: 「メモリー不足」のタイプの動作が起きています。

    ソリューション: これは、最大ヒープ・サイズが過小に設定されていることに起因する可能性があります。 SIP アプリケーションは、セッションが長いコール保持時間の間存在するために、多量のメモリーを消費する場合があります。 最大ヒープ・サイズが 512 MB では、SIP トラフィック・ワークロードには十分なメモリー容量とはいえません。 SIP アプリケーション用の最大ヒープ・サイズは、最小推奨値である 768 MB 以上に設定してください。

  • 症状: SIP 要求を SIP コンテナーへ送信したときに、「403 禁止」を受信します。

    ソリューション: これは、通常の場合、受信した SIP 要求を処理する適切な SIP アプリケーションが見つからない (メッセージに一致するルールがない) ことを意味します。


トピックのタイプを示すアイコン タスク・トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsip_trouble
ファイル名:tsip_trouble.html