SIP アプリケーションのトラブルシューティング
このトピックを使用し、SIP アプリケーションをトラブルシューティングすることができます。
このタスクについて
SIP アプリケーションに関する問題をトラブルシューティングするときに、以下の SIP コンテナーのトラブルシューティングの基本を使用します。
- システムの平均 CPU 使用率は、60% から 70% の数値を超えないようにすべきです。
- コンテナーは、割り振られた VM ヒープ・サイズの 70% を超えないように使用する必要があります。 システムに十分な物理メモリーがあり、VM ヒープ・サイズに対応できることを確認してください。 コール・ロードとセッション・タイムアウトは、ヒープ使用率に大きな影響を与えます。
- コンテナーが稼働している VM の最大ガーベッジ・コレクション (GC) 時間は、 500 ミリ秒を超えてはなりません。またその平均は 400 ミリ秒未満でなければなりません。 冗長 GC を使用してこれを測定することができ、また PMI ビューアーを使用して GC 時間、ヒープ使用率、アクティブ・セッションなどをグラフィック形式で表示することができます。
手順
- 構成の listen ポートを確認します。
- netstat –an を使用して listen ポートを確認します。
- 仮想ホストが定義されているかどうかを確認します。
- ホスト別名が定義されているかどうかを確認します。
- アプリケーションは、インストールされていますか。開始していますか。
- プロキシー構成の場合、デフォルト・クラスターは構成されていますか。 プロキシーとサーバーがマシン上にある場合は、ポートが競合していませんか。
タスクの結果
- 症状: 再送信が多く、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.log、SystemErr.log、trace.log、activity.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 アプリケーションが見つからない (メッセージに一致するルールがない) ことを意味します。