| Oracle® WebLogic Communication Services 管理ガイド 11g リリース 1 （11.1.1) B55505-01 |
|
 戻る |
 次へ |
以下の節では、Oracle WebLogic Communication Services の「エコー サーバ」プロセスをコンフィグレーションし、サーバがネットワークから物理的に切断された場合の SIP データ層のフェイルオーバ パフォーマンスを向上させる方法について説明します。
サーバ インスタンスの障害は、さまざまな出来事によって引き起こされます。1 つの障害が別の障害のきっかけになることも少なくありません。停電、ハードウェアの故障、オペレーティング システムのクラッシュ、ネットワーク パーティション、アプリケーションの予期しない動作は、いずれもサーバ インスタンスの障害の一因になり得ます。
Oracle WebLogic Communication Services では、障害発生時の影響を最小限に抑えるための基盤として、高度にクラスタ化されたアーキテクチャを使用しています。ただし、個々のサーバまたはサーバ マシンに障害が発生した場合にそなえて、クラスタ環境でも適切な回復プロセスを用意しておく必要があります。
以下の節では、Oracle WebLogic Communication Services の障害回避機能と回復機能をまとめたものであり、Oracle WebLogic Communication Services ドメインのさまざまな部分を復元するため必要なコンフィグレーション アーティファクトを説明します。
Oracle WebLogic Communication Services およびその基盤である WebLogic Server プラットフォームでは、サーバを障害から保護する多くの機能を提供します。プロダクション システムでは、継続的なサービスを保証するためにすべての利用可能な機能を使用する必要があります。
Oracle WebLogic Communication Services は、デプロイ済み SIP Servlets のパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出し、あらかじめ定義された負荷のしきい値に達するとメッセージの処理を自動的に規制します。
オーバーロード保護を使用すると、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する障害を回避することができます。
Oracle WebLogic Communication Services は、以下のような特定の状況が発生したときに障害の回避を試みます。
SIP セッションの作成レートがコンフィグレーション済みの値に達したとき
SIP タイマーおよび SIP リクエスト処理実行キューのサイズがコンフィグレーション済みの値に達したとき
基盤となる WebLogic SIP Server プラットフォームは、デプロイ済みアプリケーションのパフォーマンスと安定性に影響を及ぼすおそれのあるシステム負荷の増加を検出します。WebLogic Server ではあらかじめ定義されたロードのしきい値で自動的に発生する障害回避アクションのコンフィグレーションを管理者に許可します。自動オーバーロード保護を使用すると、予期しないレベルのアプリケーション トラフィックやリソース使用率が原因で発生する以下のような障害を回避することができます。
作業負荷マネージャがキャパシティを超過
HTTP セッション数があらかじめ定義されたしきい値まで増加
差し迫ったメモリ不足
専用のクラスタで複数のエンジン層サーバを使用すると共に、専用の SIP データ層クラスタで複数の SIP データ層サーバ (レプリカ) を使用することにより、アプリケーションの信頼性と可用性を向上させることができます。エンジン層クラスタは SIP ダイアログ (呼) に関するステートフルな情報を保持しないので、エンジン層サーバで障害が起きてもデータが失われたり呼が切断されたりすることはありません。SIP データ層パーティションの複数のレプリカには呼状態情報の冗長コピーが保存され、1 つのレプリカで障害が起きると相互に自動的にフェイルオーバされます。
WebLogic Server の自己管理モニタ機能はドメイン内のサーバ インスタンスの信頼性と可用性を向上させます。各サーバ インスタンス内の選択されたサブシステムは、そのサブシステムに特定の条件に基づいて状態をモニタします (たとえば、JMS サブシステムは JMS スレッド プールの状態をモニタし、コア サーバ サブシステムはデフォルトおよびユーザ定義実行キューの統計をモニタします)。あるサブシステムが一貫した信頼のおける方法で動作しないと判断された場合、その状態がホスト サーバに「failed」として登録されます。
次に各 WebLogic Server インスタンスは、全体的に稼動が可能であるか判断するために、登録されたサブシステムの状態をチェックします。1 つまたは複数の必須のサブシステムが FAILED 状態に達した場合、サーバ インスタンスはアプリケーションを確実にホストできないことを示すためにそれ自体の状態を FAILED にマークします。
ノード マネージャと組み合わせて使用すると、サーバの自動状態モニタ機能で、障害が発生したサーバを自動的に再起動することができます。これにより、ドメインの全体的な信頼性が向上し、管理者による直接の操作が不要になります。
管理対象サーバは、ドメイン コンフィグレーションのローカル コピーを保持しています。起動時に、管理対象サーバは管理サーバに接続し、自身が最後に停止してからドメイン コンフィグレーションに加えられた変更を取得します。起動時に管理サーバに接続できない場合は、ローカルにキャッシュされたコンフィグレーション情報を使用します。この情報は、管理対象サーバが最後に停止した時点で最新だったコンフィグレーションです。管理サーバに接続してコンフィグレーションの更新情報をチェックせずに起動した管理対象サーバは、「管理対象サーバ独立 (MSI)」モードで実行されます。デフォルトでは、MSI モードは有効になっています。
Linux または UNIX オペレーティング システムを使用している場合、ネットワーク層サーバのマシンに障害が発生した場合やネットワークからパーティションされた場合に自動的に候補 (バックアップ) サーバを起動するため、WebLogic Server のサーバ移行機能を使用することができます。サーバ移行機能はノード マネージャを wlsifconfig.sh wlsifconfig.sh スクリプトと組み合わせて使い、浮動 IP アドレスを使用して自動的に候補サーバを起動します。 ネットワーク層インスタンスをホストするプライマリ サーバにアクセスができなくなった場合のみ、候補サーバが起動されます。サーバ移行機能の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方』ドキュメントの「Whole Server Migration」を参照してください。
サーバ インスタンスの障害から回復するには、ドメインのコンフィグレーション データにアクセスする必要があります。デフォルトでは、管理サーバはドメインのプライマリ コンフィグレーション データを domain_name/config/config.xml というファイルに保存します。ここで、domain_name はドメインのルート ディレクトリです。一次コンフィグレーション ファイルは、JDBC や JMS など特定の WebLogic Server サービス、および SIP コンテナ プロパティや SIP データ層コンフィグレーションなどの Oracle WebLogic Communication Services サービスに対して、追加コンフィグレーション ファイルを参照する可能性があります。特定のサービス用コンフィグレーションは、domain_name/config ディレクトリのサブディレクトリ内の追加 XML ファイルに保存されます。たとえば、Oracle WebLogic Communication Services コンフィグレーション ファイルの domain_name/config/jms、domain_name/config/jdbc、domain_name/config/custom などです。
管理サーバはドメイン コンフィグレーションの複数のバージョンを自動的にアーカイブすることができます (domain-name/config ディレクトリ全体)。偶発的に変更されたコンフィグレーションを元に戻す必要がある場合、システムを復旧するためにコンフィグレーション アーカイブを使用することができます。たとえば、管理者がコンフィグレーションされたリソースを誤って削除した場合、最後に行われた自動バックアップを使用して以前のコンフィグレーションを復元することができます。
管理サーバは domain_name/config でローカル的に有限数の自動化されたバックアップだけを保存します。このため、ハードディスクに障害が発生した場合などのデータ破損に対処できる自動ドメイン バックアップの機能は限られています。自動バックアップでも、LDAP リポジトリ データおよびサーバ起動スクリプトなど、ドメインを完全に回復するために必要なコンフィグレーションデータは保持されません。コンフィグレーションとセキュリティの複数のバックアップ コピーをオフラインでソース コントロール システムに維持しておくことをお勧めします。
ここでは、Oracle WebLogic Communication Services で自動的に実行されるファイルのバックアップ、および管理者が定期的に実行する手動のバックアップ手順について説明します。
ドメインの管理サーバ上で、自動ドメイン コンフィグレーション バックアップを有効するには、以下の手順に従います。
ドメインの Administration Console にアクセスします。
Administration Console の左ペインで、ドメイン名を選択します。
右ペインで、[コンフィグレーション｜一般] タブをクリックします。
[詳細] を選択して、詳細なオプションを表示します。
[コンフィグレーション アーカイブを有効化] を選択します。
[アーカイブ コンフィグレーション数] ボックスに、保存するコンフィグレーション ファイル リビジョンの最大数を入力します。
[保存] をクリックします。
コンフィグレーション アーカイブを有効にすると、管理サーバではコンフィグレーション JAR ファイル アーカイブが自動的に作成されます。JAR ファイルには前のコンフィグレーションの完全なコピー (domain-name\config ディレクトリのすべてのコンテンツ) が含まれています。 JAR ファイルのアーカイブ ファイルは domain-name\configArchive ディレクトリに格納されています。 ファイルは命名規則 config-number.jar を使用します。number はアーカイブの連番です。
ドメインのコンフィグレーションに対する変更を保存すると、管理サーバは変更前のコンフィグレーションを domain-name\configArchive\config.xml#n に保存します。 管理サーバが configArchive ディレクトリにファイルを保存するたびに、#n サフィックスの値が、コンフィグレーション可能なコピーの数 (デフォルトでは 5) になるまで増えていきます。 それ以降は、ドメインのコンフィグレーションを変更するたびに、以下のような処理が行われます。
アーカイブ済みのファイルが循環し、最新のファイルに最も大きい番号のサフィックスが付けられます。
以前にアーカイブされたファイルの名前に付いた番号は 1 つずつ小さくなります。
最も古いファイルが削除されます。
コンフィグレーション アーカイブはドメイン ディレクトリ内にローカルに格納されるので、選択した最大改訂数を超えると上書きされることに注意してください。このため、節 8.1.2.2「ドメインのコンフィグレーション オフラインの格納」で説明するように、ドメイン コンフィグレーションの独自のオフライン アーカイブも作成する必要があります。
自動バックアップにより偶発的なコンフィグレーションへの変更は防止できますが、ドメイン コンフィグレーションを格納するハード ディスクの障害によって発生するデータ損失やドメイン ディレクトリの偶発的削除は防げません。これらの障害から保護するには、ソース コントロール システムでドメイン コンフィグレーション オフライン全体のコピーも格納する必要があります。
定期的にドメイン コンフィグレーションのコピーを保存することをお勧めします。たとえば、次の場合には、コンフィグレーションの最新の改訂をバックアップします。
プロダクション システムを最初にデプロイした場合
デプロイされたアプリケーションを追加または除去した場合
コンフィグレーションをパフォーマンスを向上させるためにチューニングした場合
その他の恒久的な変更を行った場合
ドメイン コンフィグレーションのバックアップには、domain_name/config ディレクトリのすべてのコンテンツを含める必要があります。 次に例を示します。
cd ~/user_projects/domains/mydomain tar cvf domain-backup-06-17-2007.jar config
ソース コントロール システムで新しいアーカイブを格納する場合、過去のある時点のドメイン コンフィグレーションを回復するために必要な以前のバージョンを保存します。
Oracle WebLogic Communication Services デプロイメントでは、一般にエンジン層サーバおよび SIP データ層サーバの起動に使われる起動スクリプトをカスタマイズし、次のようなドメイン固有のコンフィグレーション情報を指定します。
SIP メッセージ処理のスループット目標を実現するために必要な JVM ガベージ コレクションのパラメータ (節 8.8「プロダクション デプロイメントにおける JVM ガベージ コレクションのチューニング」を参照)。エンジン層サーバと SIP データ層サーバの起動には、普通は別々のパラメータが (したがって別々の起動スクリプトが) 使用されます。
Oracle WebLogic Communication Services ハートビート メカニズムのコンフィグレーション パラメータおよび起動情報。ハートビート メカニズムを使用する場合は、エンジン層サーバの起動スクリプトで、ハートビート メカニズムの有効化およびコンフィグレーションを行う起動オプションを指定します。SIP データ層サーバの起動スクリプトでは、ハートビートを有効化して WlssEchoServer プロセスを起動する起動オプションを指定します。
ドメイン内のエンジン層サーバ、SIP データ層サーバ、または Diameter リレー サーバの起動に使われる個別の起動スクリプトをバックアップします。
Oracle WebLogic Communication Services ロギング サーブレット (節 8.7「SIP リクエストと応答のロギング」を参照) を使用して SIP メッセージの定期的なロギングや監査を行う場合は、アプリケーションのソース ファイル全体をバックアップし、ステージング サーバで障害が発生した場合や元のデプロイメント ディレクトリが破損した場合にアプリケーションを簡単に再デプロイできるようにします。
WebLogic Security サービスは、コンフィグレーション データを config.xml ファイルに保存し、さらに LDAP リポジトリや他のファイルにも保存します。
すべてのサーバは SerializedSystemIni.dat という名前のファイルを作成し、サーバのルート ディレクトリに保存します。このファイルには、サーバの起動時に必要な暗号化されたセキュリティ データが記載されています。このファイルをバックアップする必要があります。
サーバで SSL を使用する場合は、セキュリティ証明書とキーもバックアップします。これらのファイルの場所はユーザがコンフィグレーションできます。
Oracle WebLogic Communication Services と共にインストールされるデフォルトの認証プロバイダ、認可プロバイダ、ロール マッピング プロバイダ、および資格マッピング プロバイダは、自身のデータを LDAP サーバに保存します。各 Oracle WebLogic Communication Services には、組み込み LDAP サーバがあります。管理サーバにはマスター LDAP サーバがあり、このサーバがすべての管理対象サーバにレプリケートされます。セキュリティ レルムでこれらのインストール済みのプロバイダを使用する場合は、次のディレクトリ ツリーの最新のバックアップを保持しておく必要があります。
domain_name\adminServer\ldap
domain_name はドメインのルート ディレクトリ、adminServer は管理サーバが実行時データやセキュリティ データを保存するディレクトリです。
LDAP ディレクトリは各 Oracle WebLogic Communication Services にありますが、バックアップする必要があるのは管理サーバの LDAP データだけです。セキュリティ データに対する更新があると、マスター LDAP サーバは各管理対象サーバの LDAP データをレプリケートします。WebLogic セキュリティ プロバイダは、ドメインの管理サーバが利用不能の間はセキュリティ データを変更できません。管理対象サーバの LDAP リポジトリはレプリカであり、変更はできません。
ldap/ldapfiles サブディレクトリには、LDAP サーバのデータ ファイルがあります。 このディレクトリ内のファイルには、ユーザ、グループ、グループ メンバシップ、ポリシー、およびロールの情報が定義されています。ldap ディレクトリの下の他のサブディレクトリには、LDAP サーバのメッセージ ログや、レプリケートされた LDAP サーバに関するデータが含まれています。
LDAP データのバックアップが行われている間は、セキュリティ プロバイダのコンフィグレーションを更新しないでください。ldap ディレクトリ ツリーをバックアップしている最中に、たとえば管理者がユーザを追加するなどしてコンフィグレーションを変更すると、ldapfiles サブディレクトリ内のバックアップの整合性が損なわれるおそれがあります。このような事態が生じた場合は、整合性が確保された、ただし最新でない可能性のある LDAP のバックアップを利用できます。
1 日に一度、サーバは書き込み処理を一時停止し、LDAP データの独自のバックアップを作成します。このバックアップは ldap\backup ディレクトリの下の ZIP ファイルにアーカイブされ、その後、書き込み処理が再開されます。このバックアップは整合性が確保されていますが、セキュリティ データが最新でない可能性があります。
オペレーティング システム レベルで保持される特定のファイルも、システム障害からの回復において非常に重要な役割を果たします。システムの必要に応じて、以下の情報をバックアップすることを検討してください。
ロード バランサのコンフィグレーション スクリプト。たとえば、エンジン層クラスタのロード バランサ プールと仮想 IP アドレス、および NAT コンフィグレーションの設定をコンフィグレーションするために使われる自動化スクリプト。
エンジン層サーバと SIP データ層サーバのシステム時計を同期するために使われる NTP クライアントのコンフィグレーション スクリプト。
各 Oracle WebLogic Communication Services マシンのホスト コンフィグレーション ファイル (ホスト名、マルチホーム マシンの仮想 IP アドレスと実際の IP アドレス、IP ルーティング テーブルの情報)。
障害が発生した管理サーバを再起動するときに、特別な手順に従う必要はありません。通常どおりの方法で管理サーバを起動してください。
管理対象サーバの実行中に管理サーバが停止した場合、ドメインの管理を回復するために、実行されている管理対象サーバを再起動する必要はありません。アクティブなドメインの管理を回復する手順は、ドメインの開始時に実行されていたのと同じマシンで管理サーバを再起動できるかどうかによって異なります。
管理対象サーバの実行中に WebLogic 管理サーバを再起動した場合、デフォルトでは、管理サーバは実行中の管理対象サーバの存在を検出することができます。
|
注意 : 起動コマンドまたは起動スクリプトで-Dweblogic.management.discover=false を指定しないでください。このオプションを指定すると、管理サーバは実行中の管理対象サーバを検出しなくなります。 |
ドメインのルート ディレクトリに running-managed-servers.xml というファイルがあり、このファイルにドメイン内の管理対象サーバのリストと、それらのサーバが実行中かどうかの情報が記載されています。管理サーバは再起動するときにこのファイルをチェックし、停止前に自身の管理下にあった管理対象サーバを確認します。
管理対象サーバが正常に、または強制的に停止されると、running-managed-servers.xml ファイル内のそのサーバのステータスが「not-running」に更新されます。管理サーバは再起動するときに、「not-running」ステータスの管理対象サーバの検出を試みません。システム クラッシュによって停止した管理対象サーバ、あるいはサーバを実行中の JVM またはコマンド プロンプト (シェル) が強制終了したために停止した管理対象サーバは、running-managed-servers.xml のステータスが「running」のままになります。管理サーバはそれらのサーバの検出を試みて、当該サーバがもはや実行されていないと判断すると例外を送出します。
管理サーバを再起動しても、管理対象サーバは静的な属性のコンフィグレーションを更新しません。「静的な属性」とは、サーバが起動処理時にのみ参照する属性です。静的なコンフィグレーション属性に対する変更を反映するには、サーバ インスタンスを再起動する必要があります。管理対象サーバの検出では、管理サーバは管理対象サーバをモニタするか、サーバの実行中にコンフィグレーションできる属性 (動的な属性) を実行時に変更することのみが可能です。
マシンがクラッシュし、同じマシンで管理サーバを再起動できない場合は、実行中の管理対象サーバの管理を次のような方法で回復できます。
新しい管理用マシンに Oracle WebLogic Communication Services ソフトウェアをインストールします (まだインストールしていない場合)。
アプリケーション ファイルをバックアップからコピーするか、共有ディスクを使用して、新しい管理サーバから利用できるようにします。新しいファイル システムでも、元の管理サーバのときと同じ相対位置でアプリケーション ファイルにアクセスできるようにする必要があります。
コンフィグレーション データおよびセキュリティ データをバックアップからコピーするか、共有ディスクを使用して、新しい管理サーバから利用できるようにします。詳細については、節 8.1.2.2「ドメインのコンフィグレーション オフラインの格納」および節 8.1.2.5「セキュリティ データのバックアップ」を参照してください。
新しいマシンで管理サーバを再起動します。
起動コマンドまたは起動スクリプトで -Dweblogic.management.discover=false を指定しないでください。このオプションを指定すると、管理サーバは実行中の管理対象サーバを検出しなくなります。
起動時に、管理サーバは管理対象サーバと通信し、管理サーバが異なる IP アドレスで実行されていることを通知します。
障害が発生した管理サーバが実行しているマシンは、ドメインの管理サーバと連絡を取ることができる場合は、ノード マネジャーを使用して管理対象サーバを手動または自動で再起動することができます。自動化された再起動をサポートするため、ノード マネージャと管理対象サーバをコンフィグレーションする必要があります。
起動時に管理サーバに接続できない場合、管理対象サーバはローカルにキャッシュされたコンフィグレーション データを読み込み、コンフィグレーションを取得することができます。この方法で起動した管理対象サーバは、管理対象サーバ独立 (MSI) モードで実行されます。
管理対象サーバを MSI モードで起動するには、次の手順に従います。
管理対象サーバのルート ディレクトリに以下のファイルがあることを確認します。
msi-config.xml
SerializedSystemIni.dat
boot.properties
管理対象サーバのルート ディレクトリにこれらのファイルがない場合は、次の手順に従います。
config.xml および SerializedSystemIni.dat ファイルを管理サーバのルート ディレクトリ (またはバックアップ) から管理対象サーバのルート ディレクトリにコピーします。
コンフィグレーション ファイルの名前を msi-config.xml に変更します。サーバを起動すると、コピーしたコンフィグレーション ファイルが使用されます。
|
注意 : -Dweblogic.RootDirectory=path 起動オプションを使用して、これらのファイルが置かれているルート ディレクトリを指定する方法もあります。 |
コマンドラインまたはスクリプトを使用して管理対象サーバを起動します。
管理対象サーバは、管理サーバからの接続があるまで MSI モードで実行されます。この状況での管理サーバの再起動については、節 8.1.3「障害の発生した管理サーバの再起動」を参照してください。
プロダクション システムでは、エンジン層サーバは SIP データ層のレプリカに頻繁にアクセスし、呼状態データの取得および書き込みを行います。Oracle WebLogic Communication Services アーキテクチャでは、SIP データ層サーバの障害や切断の検出がエンジン層ノードに任されています。レプリカが利用不能となり、呼状態データにアクセスも書き込みもできなくなると、エンジンは同じパーティション内の別のレプリカに接続し、オフライン状態にあるサーバのことを報告します。レプリカは SIP データ層の現在のビューを更新し、オフライン状態にあるサーバをビューに反映させます。他のエンジンは呼状態データにアクセスしてデータを取得するときに、この更新されたビューの情報を受け取ります。
デフォルトでは、エンジン層サーバはレプリカに対する RMI 接続を使用して、レプリカで障害が発生したのか、ネットワークから切断されたのかを判断します。RMI 接続の障害を判断するために使われるアルゴリズムは、信頼性は高いものの、最終的には TCP プロトコルの再送信タイマーを利用して切断を診断します (たとえば、レプリカへのネットワーク ケーブルが外れているかどうか)。一般に、TCP の再送信タイマーは丸 1 分間以上持続するため、Oracle WebLogic Communication Services には障害を検出するための別の方法が用意されています。この方法では、切断されたレプリカをわずか数秒で診断することができます。
WlssEchoServer は、SIP データ層のレプリカと同じサーバ ハードウェア上で実行できる独立したプロセスです。WlssEchoServer の目的は、たとえばネットワーク ケーブルが切断された場合に SIP データ層サーバがオフライン状態になったことを判断できるように、簡単な UDP エコー サービスをエンジン層ノードに提供することです。WlssEchoServer を使って障害を検出するためのアルゴリズムは次のようなものです。
通常のすべてのトラフィックについては、エンジン層サーバは TCP を使用して SIP データ層のレプリカと通信します。WlssEchoServer を使用しているかどうかにかかわらず、エンジン層と SIP データ層の間の基本トランスポートには TCP が使用されます。
エンジン層サーバは、コンフィグレーションされた各 WlssEchoServer に対し、UDP を介してハートビート メッセージを定期的に送信します。通常の運用時には、WlssEchoServer はハートビートに応答し、それによってエンジン ノードとレプリカの間の接続が確認されます。
SIP データ層スタックで全面的な障害が発生した場合、またはネットワーク ケーブルが切断された場合は、ハートビート メッセージがエンジン ノードに返されません。このような場合、エンジン ノードは通常の TCP 接続タイムアウトを待たずに、レプリカをオフライン状態と見なすことができます。
オフライン状態にあるサーバを特定した後、エンジン ノードは利用可能な SIP データ層のレプリカに障害を報告し、前の節で説明したように SIP データ層のビューが更新されます。
また、SIP データ層サーバが、自身のローカル WlssEchoServer プロセスが停止したことを検出すると、そのサーバは自動的に停止します。この動作により、節 8.2「フェイルオーバ検出の概要」で説明したエンジン ノードによる障害の検出と報告が不要になるため、フェイルオーバの時間がさらに短縮されます。
エンジン層サーバでハートビート メカニズムをコンフィグレーションし、必要に応じてフェイルオーバ検出のパフォーマンスを向上させることができます。また、WlssEchoServer がデータ層サーバ上で使用するリスン ポートとログ ファイルをコンフィグレーションすることもできます。
別のエンジン層サーバが特定のレプリカで交信することができない場合、エンジンは SIP データ層でオフライン サーバを報告するために、別の利用可能なレプリカにアクセスします。レプリカは、影響を受けるパーティションのビューを更新してオフラインサーバを削除します。次に更新されたビューはその後パーティションにアクセスするすべてのエンジン層サーバに配布されます。このようにビューを伝播することで、エンジン サーバのオフライン レプリカへのアクセスを防止することができます。
ビューを更新するレプリカは、オフライン レプリカに停止を求めるリクエストを 1 回のみ行ないます。これにより、ネットワーク故障のために 1 つまたは複数のエンジン サーバがアクセスできない実行中のレプリカ サーバを停止することができます。アクティブなレプリカが「オフライン」状態のレプリカに達した場合は、オフライン レプリカは停止します。
|
注意 : Oracle WebLogic Communication Services のすべてのインストール環境でWlssEchoServer を使用する必要はありません。エコー サーバは、コンフィグレーションされた TCP タイムアウト間隔より速くネットワークやレプリカの障害を検出する必要がある場合にのみ有効にしてください。 |
WlssEchoServer を使用してレプリカの障害を検出する場合は、以下の要件と制約に注意してください。
ハートビート メカニズムを使用して障害を検出する場合は、各レプリカ サーバ マシンで WlssEchoServer プロセスを常に実行しておく必要があります。WlssEchoServer プロセスで障害が起きたりプロセスが停止したりした場合は、たとえサーバ プロセスに影響が及んでいなくてもレプリカは「オフライン状態」として扱われます。
WlssEchoServer は、そのサーバ マシン上で利用できるすべての IP アドレスでリスンします。
WlssEchoServer には、ハートビート メッセージをリスンするための専用のポート番号が必要です。
WlssEchoServer は、シェルまたはコマンド プロンプトから直接起動できる Java プログラムです。WlssEchoServer を起動するための基本的な構文は次のとおりです。
java -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar options com.bea.wcp.util.WlssEchoServer
WLSS_HOME は、Oracle WebLogic Communication Services インストール環境のパスです。options には、表 8-1 に示すいずれかのオプションを指定できます。
表 8-1 WlssEchoServer のオプション
| オプション | 説明 |
|---|---|
-Dwlss.ha.echoserver.ipaddress |
|
-Dwlss.ha.echoserver.port |
ハートビート メッセージをリスンするポート番号を指定します。サーバ マシンの他のプロセスが同じポート番号を使用していないことを確認します。デフォルトでは、 |
-Dwlss.ha.echoserver.logfile |
ログ ファイルの場所と名前を指定します。デフォルトでは、ログ メッセージは |
WlssEchoServer を起動するコマンドは、各 Oracle WebLogic Communication Services の SIP データ層インスタンスの起動に使用するのと同じスクリプトで指定することをお勧めします。startManagedWebLogic.sh スクリプトを使ってエンジン層サーバまたは SIP データ層サーバのインスタンスを起動している場合は、サーバを起動する最後のコマンドの前に WlssEchoServer を起動するコマンドを追加します。たとえば、次の行を編集し、
"$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} \
-Dweblogic.Name=${SERVER_NAME} \
-Dweblogic.management.username=${WLS_USER} \
-Dweblogic.management.password=${WLS_PW} \
-Dweblogic.management.server=${ADMIN_URL} \
-Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \
weblogic.Server
次のように書き換えます。
"$JAVA_HOME/bin/java" -classpath WLSS_HOME/server/lib/wlss/wlssechosvr.jar \ -Dwlss.ha.echoserver.ipaddress=192.168.1.4 \ -Dwlss.ha.echoserver.port=6734 com.bea.wcp.util.WlssEchoServer & "$JAVA_HOME/bin/java" ${JAVA_VM} ${MEM_ARGS} ${JAVA_OPTIONS} \ -Dweblogic.Name=${SERVER_NAME} \ -Dweblogic.management.username=${WLS_USER} \ -Dweblogic.management.password=${WLS_PW} \ -Dweblogic.management.server=${ADMIN_URL} \ -Djava.security.policy="${WL_HOME}/server/lib/weblogic.policy" \ weblogic.Server
WlssEchoServer ハートビート メカニズムを有効にするには、すべてのエンジン層サーバおよび SIP データ層サーバを起動するコマンドで -Dreplica.host.monitor.enabled JVM 引数を指定する必要があります。 このオプションは、システムの管理対象サーバを起動するスクリプトに直接追加することをお勧めします。たとえば、startManagedWebLogic.sh スクリプトの次の行を編集し、
# JAVA_OPTIONS="-Dweblogic.attribute=value -Djava.attribute=value"
次のように書き換えます。
JAVA_OPTIONS="-Dreplica.host.monitor.enabled=true"
ハートビート メカニズムの機能をコンフィグレーションする追加の JVM オプションがいくつかあります。表 8-1 に、障害検出をコンフィグレーションするためのオプションを示します。
表 8-2 WlssEchoServer のオプション
| オプション | 説明 |
|---|---|
-Dreplica.host.monitor.enabled |
ハートビート メカニズムを有効にするには、エンジン層サーバと SIP データ層サーバの両方でこのシステム プロパティを指定する必要があります。 |
-Dwlss.ha.heartbeat.interval |
ハートビート メッセージの間隔をミリ秒単位で指定します。デフォルトでは、ハートビート メッセージは 1,000 ミリ秒ごとに送信されます。 |
-Dwlss.ha.heartbeat.count |
ハートビート メッセージへの応答が、ここで指定した回数だけ連続して返らなかった場合、レプリカはオフライン状態と見なされます。デフォルトでは、サーバの |
-Dwlss.ha.heartbeat.SoTimeout |
UDP ソケットのタイムアウト値を指定します。 |
Oracle WebLogic Communication Services には、エンジン層と SIP データ層のサーバ インスタンスのアクティビティをモニタするための専用 SNMP MIB が用意されています。Oracle WebLogic Communication Services の MIB は、ドメインの管理サーバと管理対象サーバの両方で生成されます。ただし、Oracle WebLogic Communication Services のエンジン層と SIP データ層のトラップを生成するのは、各層を構成する管理対象サーバ インスタンスだけです。管理サーバが sipserver のカスタム リソースのための対象でなければ、(クラスタ内のサーバで障害が起きた場合などに) WebLogic Server の SNMP トラップのみが生成されます。管理者は、ドメイン全体の動作を評価するために、WebLogic Server と Oracle WebLogic Communication Services の両方のトラップをモニタする必要があります。
|
注意 : Oracle WebLogic Communication Services の MIB オブジェクトは読み込み専用です。SNMP を使用して Oracle WebLogic Communication Services のコンフィグレーションを変更することはできません。 |
Oracle WebLogic Communication Services の MIB ファイルは、WLSS_HOME/server/lib/wlss/BEA-WLSS-MIB.asn1 にインストールされています。 このファイルの内容を表示するには、利用可能な SNMP 管理ツールまたは MIB ブラウザを使用してください。共有 SNMP トラップの説明については、節 8.5.2「トラップの説明」を参照してください。
Oracle WebLogic Communication Services ドメイン全体の SNMP モニタを有効にするには、次の手順に従います。
Oracle WebLogic Communication Services ドメインの Administration Console にログインします。
左ペインで、[Diagnostics｜SNMP] ノードを選択します。
新しいエージェントを作成するには、Server SNMP エージェント テーブルで [New] ボタンをクリックしてください。
|
注意 : Domain-Scoped エージェントではなく新しい Server SNMP エージェントを作成することを確認します。 |
新しい SNMP エージェントに固有の名前 (たとえば、「engine1snmp」) を入力して、[OK] をクリックします。
Server SNMP エージェント テーブルから、作成した新しい SNMP エージェントを選択します。
[コンフィグレーション｜一般] タブで以下のように選択します。
[有効化] チェック ボックスを選択し、エージェントを有効にします。
SNMP UDP ポート フィールドで非使用のポート番号を入力します。
|
注意 : 複数の管理対象サーバ インスタンスを同じマシンで実行する場合、各サーバ インスタンスはユニークな SNMP ポート番号で専用 SNMP エージェントを使用する必要があります。 |
[保存] をクリックします。
デプロイメント内の各サーバ （SIP データ層サーバ、エンジン層サーバおよび管理サーバ）に対してユニークな SNMP エージェントを生成するには、上記の手順を繰り返します。
以下の節では、Oracle WebLogic Communication Services の SNMP トラップについて詳しく説明します。また、個々のトラップに対処するための回復手順についても必要に応じて説明します。
以下の Oracle WebLogic Communication Services のログ ファイルおよびコンフィグレーション ファイルはトラブルシューティングに役立つことが多く、テクニカル サポートへの問い合わせの際に必要になることがあります。
$DOMAIN_DIR/config/config.xml
$DOMAIN_DIR/config/custom/sipserver.xml
$DOMAIN_DIR/servername/*.log (サーバおよびメッセージ ログ)
sip.xml (アプリケーションの /WEB-INF サブディレクトリ内)
web.xml (アプリケーションの /WEB-INF サブディレクトリ内)
テクニカル サポート チームが問題を解決する上で、次のような一般情報が役立つことがあります。
以下のソフトウェアの具体的なバージョン番号
Oracle WebLogic Communication Services
Java SDK
オペレーティング システム
ハングした Oracle WebLogic Communication Services プロセスのスレッド ダンプ
ネットワーク アナライザのログ
表 8-3 は、Oracle WebLogic Communication Services の各種 SNMP トラップをエンジン層のサーバで生成されるトラップと SIP データ層のサーバで生成されるトラップに分けて示したものです。 それぞれのトラップについては、表に続く各節で説明します。
表 8-3 Oracle WebLogic Communication Services の SNMP トラップ
| トラップが生成されるサーバ ノード | トラップ名 |
|---|---|
|
エンジン層サーバ |
節 8.5.2.1「connectionLostToPeer」 |
|
節 8.5.2.2「connectionReestablishedToPeer」 |
|
|
節 8.5.2.4「overloadControlActivated、overloadControlDeactivated」 |
|
|
|
|
|
|
|
|
節 8.5.2.11「sipAppFailedToDeploy」 |
|
|
エンジン層サーバと SIP データ層サーバ (サーバがクラスタのメンバーである場合) |
|
|
SIP データ層サーバ |
節 8.5.2.3「dataTierServerStopped」 |
|
節 8.5.2.5「replicaAddedToPartition」 |
|
|
節 8.5.2.6「replicaRemovedEnginesRegistration」 |
|
|
節 8.5.2.7「replicaRemovedFromPartition」 |
エンジン層のサーバ インスタンスが SIP データ層のレプリカに接続できなくなった場合は、そのエンジン層サーバでこのトラップが生成されます。エンジン層と SIP データ層の間でネットワーク接続の問題が起きている可能性があります。また、SIP データ層のサーバで障害が発生している場合は、このトラップと共に追加のトラップが生成されることがあります。
以前に接続に失敗したエンジン層のサーバ インスタンスが (connectionLostToPeer トラップが生成された後で) SIP データ層のサーバへの再接続に成功した場合は、そのエンジン層サーバでこのトラップが生成されます。このトラップが繰り返し発生する場合は、エンジン層と SIP データ層の間で断続的なネットワーク障害が起きている可能性があります。
データ層に属する WebLogic Server インスタンスで回復不能なエラーが発生した場合は、Oracle WebLogic Communication Services の SIP データ層ノードでこのアラームが生成されます。このトラップは、エラーによって停止しようとしているサーバ自体で生成される場合と、同じパーティション内の別のレプリカで生成される場合があり、一部のケースでは両方のサーバで生成されることもあります (ネットワークの障害発生時には両方のサーバで同じトラップが生成されることがあります)。
Oracle WebLogic Communication Services のエンジン層ノードでは、処理される新しい SIP リクエストの数を制御できるように、コンフィグレーション可能なスロットル機能のメカニズムが使われています。コンフィグレーションされているオーバーロード状態に達すると、Oracle WebLogic Communication Services は新しい SIP リクエストを破棄し、呼び出し側に「503 Service Unavailable」で応答します。コンフィグレーションされているしきい制御値に従って、オーバーロード状態が解消するまでサーバは新しいリクエストを破棄し続けます。このアラームは、スロットル機能のメカニズムがアクティブになっているときに生成されます。スロットル機能の動作により、サーバは最終的にオーバーロードでない状態に戻るので、それ以上のアクションは必要ありません。
サーバ インスタンスがデータ層のパーティションに追加された場合は、Oracle WebLogic Communication Services の SIP データ層ノードでこのアラームが生成されます。
登録されていない (または登録済みエンジンのリストから削除されている) エンジン サーバ クライアントが SIP データ層と通信しようとすると、SIP データ層ノードでこのアラームが生成されます。 一般に、このトラップはserverStopped トラップの後に続きます。これは、SIP データ層の一貫性を保持するためにエンジン層サーバはシャットダウンされていること示しています。
通常の停止操作によって、または障害が原因でサーバが SIP データ層から削除された場合は、Oracle WebLogic Communication Services の SIP データ層ノードでこのアラームが生成されます。このトラップが生成されるのは、サーバの削除後、そのパーティション内で少なくとも 1 つのレプリカが動作し続けている場合だけです。レプリカが 1 つしか存在しないパーティションでそのレプリカに障害が発生した場合は、トラップを生成できません。また、レプリカに障害が発生したことはエンジン層のノードによって検出されるので、このトラップが生成可能であるためには、いずれかのエンジン層ノードが実行されている必要があります。
このトラップは、WebLogic Server インスタンスが現在ダウンしていることを示します。このトラップはエンジン層と SIP データ層の両方のサーバ インスタンスに適用されますが、それは、サーバが名前付きの WebLogic Server クラスタのメンバーである場合に限られます。このトラップが、制御された停止によって発生したのではなく、自然に生成された場合は、次の手順に従います。
次の回復手順を実行します。
次のコマンドを使用して、ハングしているプロセスを特定します。
ps – ef | grep java
マシンで実行中の WebLogic Server インスタンスごとに、対応する PID が 1 つだけあります。
影響を受けている PID を特定したら、次のコマンドを使ってプロセスを強制停止します。
kill -3 [pid]
このコマンドを実行すると、実際のスレッド ダンプが生成されます。プロセスが直ちに停止しない場合は、潜在的なデッドロックの問題の診断に役立つように、プロセスが停止するまで 5 ～ 10 秒間隔でコマンドを何度か繰り返します。
すぐに Oracle WebLogic Communication Services を再起動してみます。
トラブルシューティングに役立つように、影響を受けたサーバのすべての SIP ログのバックアップ コピーを作成します。ログの場所は、サーバのコンフィグレーションによって異なります。
Tier 4 サポートが問題を解決する際に役立つように、各ログをコピーします。
|
注意 : Oracle WebLogic Communication Services のログは、システムのコンフィグレーションに従って切り捨てられます。重要なトラブルシューティングの情報が失われないように、バックアップ ログを直ちに作成してください。 |
Tier 4 サポートに連絡し、トラブル チケットにログ ファイルを含めます。
その後 24 時間にわたり、サーバを注意深くモニタします。ログ ファイルで問題の原因を特定できない場合は、ハードウェアやネットワークに問題があり、それが時間をおいて再発することがあります。
SIP サーブレットがコンテナにデプロイされた場合は、Oracle WebLogic Communication Services のエンジン層ノードでこのアラームが生成されます。
SIP アプリケーションが停止した場合、または SIP アプリケーションがアンデプロイされた場合は、Oracle WebLogic Communication Services のエンジン層ノードでこのアラームが生成されます。一般に、アクティブなリクエストがまだ存在するにもかかわらず Oracle WebLogic Communication Services が停止した場合に発生します。
アプリケーションが Web アプリケーションとしては正しくデプロイされたが、SIP アプリケーションとしてデプロイされなかった場合は、Oracle WebLogic Communication Services のエンジン層ノードでこのトラップが生成されます。
WebLogic 診断フレームワーク (WLDF) は、WebLogic Server インスタンスとそのアプリケーションの診断情報を収集、アーカイブおよびアクセスするために共同作業する数多くのコンポーネントから構成されています。Oracle WebLogic Communication Services バージョン は、WLDF のさまざまなコンポーネントと統合することにより、デプロイ済み SIP Servlets と共にエンジンおよび SIP データ層ノードの操作をモニタし、診断します。
データ コレクタ - Oracle WebLogic Communication Services は、ハーベスタ サービスと統合するとて実行時 MBeans からの情報を収集し、Logger サービスと統合すると SIP リクエストと応答をアーカイブすることができます。
監視と通知 - 管理者は監視と通知コンポーネントを使用して、Oracle WebLogic Communication Services の実行時 MBean の属性に基づき複雑なルールを作成することができます。これらの属性は、JMS、JMX、SNMP および SMTP などを使用して自動通知をトリガします。
イメージ キャプチャ - Oracle WebLogic Communication Services インスタンスは、管理者からリクエストされた場合、一定の診断データを収集し、イメージ ファイルに書き込むことができます。このデータは、実行中のサーバに起こる問題を診断するために使用できます。
インスツルメンテーション - Oracle WebLogic Communication Services では、モニタを使用してサーバ コードとアプリケーション コードをインスツルメンテーションするので、特定の条件に一致する SIP メッセージ (リクエストと応答) について実行する診断アクションをコンフィグレーションすることができます。
以下の節では、上記の各 WLDF コンポーネントと Oracle WebLogic Communication Services の統合方法の詳細について説明します。
Oracle WebLogic Communication Services は、以下の実行時 MBeans の属性からデータを収集するために WLDF のハーベスタ サービスを使用します。
ReplicaRuntimeMBean
SipApplicationRuntimeMBean
SipServerRuntimeMBean
WLDF コンソール拡張を使用して、ユーザのカスタム ビューにデータの図とグラフを追加することができます。これを行うには、最初に以下のようにドメイン ディレクトリの console-ext サブディレクトリに JAR ファイルをコピーして WLDF コンソール拡張を有効にします。
cp ~/bea/wlserver_10.3/server/lib/console-ext/diagnostics-console-extension.jar ~/bea/user_projects/domains/mydomain/console-ext
WLDF コンソール拡張にアクセスすると、Oracle WebLogic Communication Services 実行時 MBean の属性が拡張の [メトリクス] タブから使用できます。
また、Oracle WebLogic Communication Services は、独立した専用のログ ファイルに SIP と Diameter メッセージをアーカイブするために WLDF Logger サービスを使用します (デフォルトでは、domain_home/logs/server_name/sipMessages.log)。 SIP Server Administration Console 拡張で [コンフィグレーション｜メッセージ デバッグ] タブを使用して、ログ ファイルの名前と場所、ならびにログ ローテーション ポリシーをコンフィグレーションすることができます。独立したロギングとログ ローテーションを開始するためには、サーバの再起動が必要です。
Oracle WebLogic Communication Services の実行時 MBean から収集したデータを使用して、サーバの診断状態を監視する自動モニタまたは「監視」を作成します。 コンフィグレーションされた監視状態およびルールが発生した場合、SMTP、SNMP、JMX、または JMS を使用してメッセージを作成するために 1 つまたは複数の通知を監視で使用するようにコンフィグレーションすることができます。
監視と通知を使用するには、Administration Console の左ペインで [診断｜診断モジュール] ノードを選択し、サーバをモニタするために必要な監視ルールおよび通知を使って新しいモジュールを作成します。監視のルールでは、Oracle WebLogic Communication Services の実行時 MBean、ログ ファイルに書き込まれたメッセージ、または診断フレームワークで作成されたイベントから収集したメトリックスを使用することができます。
Oracle WebLogic Communication Services は、独自のイメージ キャプチャ情報を WLDF で作成された診断イメージに追加します。診断イメージは、要求に応じて生成するか、監視ルールをコンフィグレーションして自動的に生成します。
診断イメージに含まれている情報については、Oracle のテクニカル サポート担当者がサーバの問題のトラブルシューティングに使用することを意図しています。これには以下の情報が含まれます。
SIP データ層パーティションとレプリカのコンフィグレーション
呼状態とタイマーの統計
ワーク マネージャの統計
WLDF インスツルメンテーション システムは、診断モニタを作成し、実行中に特定のポイントで Oracle WebLogic Communication Services またはアプリケーション コードに挿入します。Oracle WebLogic Communication Services をインスツルメンテーションサービスと統合して、組み込み DyeInjection モニタを提供します。このモニタが使用可能になると、特定の SIP メッセージがシステムに入力された場合、またはすでに存在する場合、診断コンテキストに仕分けフラグがインジェクトされます。仕分けフラグはモニタのコンフィグレーション プロパティと一定のリクエスト属性に基づいてインジェクトされています。
Oracle WebLogic Communication Services は、WebLogic Server の仕分けフラグの USSR と ADDR に加え、以下の表 8-4 に説明されている仕分けフラグも追加します。 詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 診断フレームワークのコンフィグレーションと使い方』を参照してください。
表 8-4 Oracle WebLogic Communication Services DyeInjection フラグ
| 仕分けフラグ | 説明 |
|---|---|
|
PROTOCOL_SIP |
すべての SIP プロトコル メッセージの診断コンテキストで設定されます。 |
|
SIP_REQ |
プロパティ SIP_REQ の値に一致するすべての SIP リクエストの診断コンテキストに設定されます。 |
|
SIP_RES |
SIP 応答がプロパティ SIP_RES の値に一致する場合に設定されます。 |
|
SIP_REQURI |
SIP リクエストの reqURI がプロパティ SIP_REQURI の値に一致する場合に設定されます。 |
|
SIP_ANY_HEADER |
SIP リクエストにプロパティ SIP_ANY_HEADER の値に一致するヘッダが含まれている場合、設定されます。 |
|
SIP_RES |
このフラグは、プロパティ SIP_RES の値に一致するすべての SIP 応答用診断コンテキストに設定されます。 |
|
SIP_REQURI |
このフラグは、SIP リクエストのリクエスト URI がプロパティ SIP_REQURI の値に一致する場合に設定されます。 |
|
SIP_ANY_HEADER |
このフラグは、SIP リクエストにプロパティ SIP_ANY_HEADER の値に一致するヘッダが含まれている場合、設定されます。SIP_ANY_HEADER の値は、 |
仕分けフラグは、着信 SIP メッセージと発信 SIP メッセージの両方に適用できます。仕分けのフィルタリング処理にフラグを使用します。委託モニタが次の診断アクションをトリガするときに使用できます。
Oracle WebLogic Communication Services には、アプリケーションおよびサーバ スコープに適用できる数多くの代理モニタがあります。これらのモニタは、DyeInjection モニタによって設定された仕分けフラグを調査することができます。 代理モニタについては、表 8-4 を参照してください。
表 8-5 Oracle WebLogic Communication Services 診断モニタ
| モニタ名 | モニタ タイプ | スコープ | ポイントカット |
|---|---|---|---|
|
occas/Sip_Servlet_Before_Service |
Before |
アプリケーション |
すべての実装サブクラスの |
|
occas/Sip_Servlet_After_Service |
After |
アプリケーション |
すべての実装サブクラスの |
|
occas/Sip_Servlet_Around_Service |
Around |
アプリケーション |
すべての実装サブクラスの |
|
occas/Sip_Servlet_Before_Session |
Before |
アプリケーション |
|
|
occas/Sip_Servlet_After_Session |
After |
アプリケーション |
|
|
occas/Sip_Servlet_Around_Session |
Around |
アプリケーション |
|
|
occas/SipSessionDebug |
Around |
アプリケーション |
これは、一定のポイントカットとデバッグアクションがある組み込みアプリケーション スコープ モニタです。ポイントカットの前後、モニタは 基になるオブジェクトをシリアライズした後で、SIP セッション のサイズを計算する モニタのポイントカットは以下のとおりです。
注意 : 注意 : Apache Ant を使用してアプリケーションをコンパイルすると、生成されたクラス ファイルに必要なデバッグ情報が埋め込まれるため、 |
|
occas/Sip_Servlet_Before_Message_Send_Internal |
Before |
サーバ |
ワイヤにメッセージを書き込む Oracle WebLogic Communication Services コードのエントリ時。 |
|
occas/Sip_Servlet_After_Message_Send_Internal |
After |
サーバ |
ワイヤにメッセージを書き込む Oracle WebLogic Communication Services コードの終了時。 |
|
occas/Sip_Servlet_Around_Message_Send_Internal |
Around |
サーバ |
ワイヤにメッセージを書き込む Oracle WebLogic Communication Services コードのエントリと終了時。 |
サーバ スコープのモニタを使用するには、新しい診断モジュールを作成して、モジュールに 1 つまたは複数のモニタを作成しコンフィグレーションする必要があります。組み込み DyeInjection モニタの場合、特定のダイ フラグを定義するためにモニタ プロパティを追加します。occas/Sip_Servlet_Before_Message_Send_Internal などの代理モニタについては、モニタ プロパティを追加して診断アクションを定義します。
Oracle WebLogic Communication Services DyeInjection モニタ、代理モニタをコンフィグレーションして仕分けフィルタリングを有効にするには、次の手順に従います。
ドメインの Administration Console にアクセスします。
コンソールの左ペインの [診断｜診断モジュール] ノードを選択します。
[新規] をクリックして、新しい診断モジュールを作成します。モジュールに「instrumentationModule」のようなわかりやすい名前を付けて、[OK] をクリックします。
テーブル内のモジュールのリストから新しい「instrumentationModule」を選択します。
[ターゲット] タブを選択します。
このモジュールを対象とするサーバを選択して、[保存] をクリックします。
[診断｜診断モジュール] ノードに戻って、モジュールのリストから「instrumentationModule」を選択します。
[コンフィグレーション｜インスツルメンテーション] タブを選択します。
[有効化] を選択し、サーバ レベルでのインスツルメンテーションを有効にして、[保存] をクリックします。
モジュールに DyeInjection モニタを追加するには、以下の手順に従います。
[追加/削除] をクリックします。
利用可能なリストからモニタの名 (たとえば、DyeInjection) を選択し、矢印を使って選択したリストに移動します。
[OK] をクリックします。
利用可能なモニタのリストから新たに作成したモニタを選択します。
モニタが有効になっていることを確認し、[プロパティ] フィールドを編集して必要なプロパティを追加します。DyeInjection モニタのサンプル プロパティには、以下が含まれています。
SIP_RES=180 SIP_REQ=INVITE SIP_ANY_HEADER=request.Contact=sip:sipp@localhost:5061
[保存] をクリックします。
モジュールに 1 つまたは複数の代理モニタを追加するには、以下の手順に従います。
新しいモジュールの名前を入力するには、[コンフィグレーション｜インスツルメンテーション] タブに戻る。
[追加/削除] をクリックします。
利用可能なリストから代理モニタ名 (たとえば、occas/Sip_Servlet_Before_Message_Send_Internal) を選択し、矢印を使って選択したリストに移動します。
[OK] をクリックします。
利用可能なモニタのリストから、新たに作成したモニタを選択します。
モニタが有効になっていることを確認し、利用可能なリストから 1 つまたは複数のアクションを選択して、矢印を使って選択したリストに移動します。occas/Sip_Servlet_Before_Message_Send_Internal モニタでは、サンプル アクションに DisplayArgumentsAction、 StackDumpAction、ThreadDumpAction、および TraceAction が含まれています。
[EnableDyeFiltering] の横にあるチェック ボックスを選択します。
利用可能なリストから SIP_REQ のような 1 つまたは複数の仕分けマスクを選択し、矢印を使って選択したリストに移動します。
[保存] をクリックします。
|
注意 : 代理モニタを追加して作成するには、上記の手順を繰り返します。 |
アプリケーション スコープ モニタを weblogic-diagnostics.xml という名前の XML コンフィグレーション ファイルにのコンフィグレーションします。weblogic-diagnostics.xml ファイルを SIP モジュールまたはエンタープライズ アプリケーションの META-INF ディレクトリに格納する必要があります。
XML ファイルは、アプリケーション レベルでインスツルメンテーションを有効化にし、ポイントカット、代理モニタ仕分けマスクおよびアクションを定義します。例 8-1 には、occas/Sip_Servlet_Before_Service モニタを使用するコンフィグレーション ファイルのサンプルを示します。
例 8-1 weblogic-diagnostics.xml ファイルのサンプル
<wldf-resource xmlns="http://www.bea.com/ns/weblogic/90/diagnostics"> <instrumentation> <enabled>true</enabled> <include>demo.ProxyServlet</include> <wldf-instrumentation-monitor> <name>occas/Sip_Servlet_Before_Service</name> <enabled>true</enabled> <dye-mask>SIP_ANY_HEADER</dye-mask> <dye-filtering-enabled>true</dye-filtering-enabled> <action>DisplayArgumentsAction</action> </wldf-instrumentation-monitor> </instrumentation> </wldf-resource>
この例では、診断コンテキストの着信するリクエストに SIP_ANY_HEADER 仕分けフラグが含まれている場合、occas/Sip_Servlet_Before_Service モニタがトリガされ、DisplayArgumentsAction が実行されます。
Oracle WebLogic Communication Services では、処理される SIP リクエストと応答の Protocol Data Unit (PDU) ロギングを行うことができます。ロギングされた SIP メッセージは、Oracle WebLogic Communication Services のドメイン全体のログ ファイル、または個々の管理対象サーバ インスタンスのログ ファイルに書き込まれます。SIP メッセージは Oracle WebLogic Communication Services インスタンスと同じログ ファイルを共有するので、ログに記録された SIP メッセージを管理するときに、ログ ローテーション、ドメイン ログ フィルタ、最大ログ サイズ コンフィグレーションなどの高度なサーバ ロギング機能を利用できます。
管理者は SIP PDU ロギングをコンフィグレーションするために、com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl クラスを使って 1 つまたは複数の SIP サーブレットを定義します。次に、定義したサーブレットのパラメータとして、またはアプリケーションと共にパッケージ化される独立した XML ファイルで、ロギング条件をコンフィグレーションします。
SIP リクエストが処理されるか、SIP 応答が生成される際に、ロギング サーブレットはスタンドアロンの XML コンフィグレーション ファイルまたはサーブレットのパラメータで定義されたフィルタ処理のパターンをメッセージと照合します。指定されたパターンと一致する SIP リクエストと応答は、ロギング サーブレットの名前、コンフィグレーションされているロギング レベル、その他の詳細と共にログ ファイルに書き込まれます。無駄なパターン マッチングを避けるために、サーブレットは最初のパターンが一致すると新しい SIP セッションにマークして、そのセッションのそれ以降のリクエストと応答を自動的にログに記録します。
ロギング条件は、sip.xml でロギング サーブレットのパラメータとして直接定義するか、外部 XML コンフィグレーション ファイルで定義します。節 8.7.3「ロギングするメッセージの条件の指定」を参照してください。
|
注意 : 技術者は、サーブレットのinit() メソッドで TraceMessageListenerFactory を使って委託を作成するか、デプロイする Java アプリケーションで追跡用のクラスを使って、サーブレットに PDU ロギング機能を実装できます。委託を使用すると、デフォルトの追跡メッセージ リスナの実装を使ってカスタム ロギングを行うことや、受信 SIP メッセージを操作することができます。サーブレットの init() メソッドでファクトリを使用する例については、節 8.7.7「SIP サーブレット コードへの追跡機能の追加」を参照してください。 |
SIP メッセージのロギング サーブレットを作成するには、実装クラス com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl を持つサーブレットを定義します。msgTraceLogger サンプルの定義を例 8-2に示します。
例 8-2 サンプルのロギング サーブレット
<servlet> <servlet-name>msgTraceLogger</servlet-name> <servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class> <init-param> <param-name>domain</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>level</param-name> <param-value>full</param-value> </init-param> <load-on-startup/> </servlet>
SIP メッセージのロギングの詳細レベルや出力先ログ ファイルなどのロギング属性は、初期化パラメータとしてロギング サーブレットに渡されます。表 8-5 に、init-param のエントリとして指定できるパラメータとパラメータ値を示します。例 8-2 には、すべての SIP メッセージ情報をドメイン ログ ファイルに記録するサーブレットの init-param サンプルのエントリの例が示されています。
ログに記録される SIP メッセージを選択するための条件は、ロギング サーブレットのアプリケーションと共にパッケージ化される XML ファイルで定義することも、サーブレットの sip.xml デプロイメント記述子で初期化パラメータとして定義することもできます。以下の節で、それぞれの方法について説明します。
ロギング サーブレットの初期化パラメータとしてロギング条件を指定しない場合、サーブレットはロギング アプリケーションの最上位にある 1 組の XML 記述子ファイル内のロギング条件を参照します。request-pattern.xml および response-pattern.xml という名前のこれらの記述子ファイルでは、ログ ファイルに記録される SIP リクエストと応答を選択するために Oracle WebLogic Communication Services が使用するパターンが定義されます。
|
注意 : デフォルトでは、Oracle WebLogic Communication Services はリクエストと応答の両方をログに記録します。応答をログに記録する必要がない場合は、空のマッチング条件を指定してresponse-pattern.xml ファイルを定義する必要があります。 |
通常のパターン定義では、SIP メッセージ ヘッダ内の特定の値を照合するための条件を定義します。たとえば、msgTraceLogger サーブレットで使われるサンプルの response-pattern.xml では、すべての MESSAGE リクエストが照合されます。この記述子の内容を次に示します。
例 8-3 msgTraceLogger サーブレットのサンプルの response-pattern.xml
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pattern PUBLIC "Registration//Organization//Type Label//Definition Language" "trace-pattern.dtd"> <pattern> <equal> <var>response.method</var> <value>MESSAGE</value> </equal> </pattern>
SIP メッセージを照合するための追加の演算子と条件については、節 8.7.6「trace-pattern.dtd リファレンス」を参照してください。 equal 条件など、ほとんどの条件には、表 8-3 に示すように評価する SIP メッセージの部分を識別する変数 (var 要素) が必要です。 表 8-5 に、一般的な変数と値の例を示します。 この他の変数名と例については、 SIP Servlet API 1.1 仕様 (http://jcp.org/en/jsr/detail?id=289) の節 16: Mapping Requests to Servlets を参照してください。 Oracle WebLogic Communication Services では、リクエストと応答の両方の変数をロギング サーブレットにマッピングすることができます。
表 8-6 パターン マッチングの変数とサンプル値
| 変数 | 値の例 |
|---|---|
|
request.method、response.method |
MESSAGE、INVITE、ACK、BYE、CANCEL |
|
request.uri.user、response.uri.user |
guest、admin、joe |
|
request.to.host、response.to.host |
server.mydomain.com |
request-pattern.xml と response-pattern.xml では、同じ文書型定義 (DTD) が使われます。詳細は、節 8.7.6「trace-pattern.dtd リファレンス」を参照してください。
パターン マッチング条件は、独立した XML ドキュメントとしてではなく、ロギング サーブレットの初期化パラメータとして指定することもできます。マッチング条件を指定するためのパラメータ名は、request-pattern-string および response-pattern-string です。これらのパラメータは、節 8.7.2「ロギング レベルと出力先のコンフィグレーション」で説明したロギング レベルや出力先と共に定義されます。
各パターン マッチング パラメータの値は、スタンドアロン パターン定義ドキュメントの DTD に準拠する有効な XML ドキュメントで構成されている必要があります (節 8.7.3.1「XML ドキュメントを使ったロギング条件の指定」を参照してください)。 パターンと値を定義する XML ドキュメントは sip.xml 記述子の一部として解析されてはならないので、コンテンツを [CDATA] タグで囲む必要があります。例 8-4 に、サンプルのロギング サーブレット invTraceLogger の sip.xml エントリ全体を示します。 最後の 2 つの init-param の要素で、INVITE リクエスト メソッドと OPTIONS 応答メソッドだけをログに記録することを指定しています。
例 8-4 init-param の要素として指定されたロギング条件
<servlet> <servlet-name>invTraceLogger</servlet-name> <servlet-class>com.bea.wcp.sip.engine.tracing.listener.TraceMessageListenerImpl</servlet-class> <init-param> <param-name>domain</param-name> <param-value>true</param-value> </init-param> <init-param> <param-name>level</param-name> <param-value>full</param-value> </init-param> <init-param> <param-name>request-pattern-string</param-name> <param-value> <![CDATA[ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pattern PUBLIC "Registration//Organization//Type Label//Definition Language" "trace-pattern.dtd"> <pattern> <equal> <var>request.method</var> <value>INVITE</value> </equal> </pattern> ]]> </param-value> </init-param> <init-param> <param-name>response-pattern-string</param-name> <param-value> <![CDATA[ <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pattern PUBLIC "Registration//Organization//Type Label//Definition Language" "trace-pattern.dtd"> <pattern> <equal> <var>response.method</var> <value>OPTIONS</value> </equal> </pattern> ]]> </param-value> </init-param> <load-on-startup/> </servlet>
デフォルトでは、Oracle WebLogic Communication Services は、テキストまたはアプリケーション /sdp Content-Type 値を有する SIP メッセージのコンテンツをログするために、文字列フォーマット (UTF-8 エンコーディング) を使用します。他のすべての Content-Type 値では、文字列セットが指定されている場合、Oracle WebLogic Communication Services はメッセージの charset パラメータに指定した文字列セットを使用してメッセージのコンテンツをログします。charsetパラメータが指定されていない場合、または charset 値が無効かサポートされていない場合、Oracle WebLogic Communication Services uses は、メッセージをログする前にメッセージ コンテンツを暗号化するために Base-64 エンコーディングを使用します。
こうした状況でメッセージのコンテンツの暗号化を回避するには、sipserver.xml の string-rep 要素を使用して String-representable Content-Type 値のリストを指定します。string-rep 要素は 1 つまたは複数の一致する content-type 要素を持つことができます。ログされたメッセージがコンフィグレーションされた content-type 要素のいずれかに一致する場合、Oracle WebLogic Communication Services は charset パラメータが含まれているか否かにかかわらず、UTF-8 エンコーディング を使用して文字列フォーマットにコンテンツをログします。
|
注意 : text/* または application/sdp のコンテンツ タイプはデフォルトとして文字列フォーマットにログされているため、指定する必要はありません。 |
例 8-5 に、text/* および application/sdp コンテンツに加え、追加の 3 つの Content-Type 値に対して文字列コンテンツをログする message-debug コンフィグレーションをサンプルとして示します。
Oracle WebLogic Communication Services のロギング インフラストラクチャでは、既存のログ ファイルが指定のサイズに達したら、自動的に新しいログ ファイルに書き込まれるようにすることができます。また、Administration Console を使ってログの内容を参照することや、ログに書き込まれる追加のサーバ レベル イベントをコンフィグレーションすることもできます。
trace-pattern.dtd では、request-pattern.xml および response-pattern.xml ドキュメントの必須コンテンツのほかに、サーブレットの init-param 変数である request-pattern-string と response-pattern-string の値も定義されます。
例 8-6 trace-pattern.dtd
<!-- さまざまなタイプの条件がサポートされています。 - > <!ENTITY % condition "and | or | not | equal | contains | exists | subdomain-of"> <!-- pattern は条件で、SIP リクエストのセットの述部です。 - > <!ELEMENT pattern (%condition;)> <!-- すべての構成条件が true の場合のみ and 条件が true になります。 - > <!ELEMENT and (%condition;)+> <!-- 少なくとも 1 つの構成条件が true の場合、or 条件が true になります。 - > <!ELEMENT or (%condition;)+> <!-- 条件内の値を否定します。 - > <!ELEMENT not (%condition;)> <!-- 変数の値が指定されたリテラル値と同じである場合、True です。 - > <!ELEMENT equal (var, value)> <!-- 変数の値が指定されたリテラル値を含む場合、True です。 - > <!ELEMENT contains (var, value)> <!-- 指定された変数がすでに存在する場合、True です。 - > <!ELEMENT exists (var)> <!-- - > <!ELEMENT subdomain-of (var, value)> <!-- 変数を指定します。 Example: <var>request.uri.user</var> - > <!ELEMENT var (#PCDATA)> <!-- ルールの指定に使用するリテラル文字列値を指定します。 - > <!ELEMENT value (#PCDATA)> <!-- equal テストが大文字と小文字を区別するかどうかを指定します。 - > <!ATTLIST equal ignore-case (true|false) "false"> <!-- contains テストが大文字と小文字を区別するかどうかを指定します。 - > <!ATTLIST contains ignore-case (true|false) "false"> <!-- ID メカニズムを使うと、ツールで簡単にデプロイメント記述子の要素 に対するツール固有の参照を行うことができます。これにより、 追加デプロイメント情報 (つまり、標準的な デプロイメント記述子情報以上の情報) を作成して 非標準情報を別のファイルに格納し、これらの ツール固有のファイルから簡単に標準 sip-app デプロイメント記述子を参照することができます。- > <!ATTLIST pattern id ID #IMPLIED> <!ATTLIST and id ID #IMPLIED> <!ATTLIST or id ID #IMPLIED> <!ATTLIST not id ID #IMPLIED> <!ATTLIST equal id ID #IMPLIED> <!ATTLIST contains id ID #IMPLIED> <!ATTLIST exists id ID #IMPLIED> <!ATTLIST subdomain-of id ID #IMPLIED> <!ATTLIST var id ID #IMPLIED> <!ATTLIST value id ID #IMPLIED>
TraceMessageListenerFactory を使用すると、独自のサーブレットや Java コードに追跡機能を追加することができます。TraceMessageListenerFactory により、クライアントはインスタンスを作成し、そのインスタンスに委託することで、デフォルトの追跡メッセージ リスナ実装の動作を再利用できるようになります。ファクトリ実装インスタンスは、SIP サーブレットのサーブレット コンテキストで TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY 属性の値を検索すると見つかります。
|
注意 : ファクトリによって作成されるインスタンスは、SIP メッセージの受信および送信時にコールバックを受け取るように Oracle WebLogic Communication Services に登録されません。 |
サーブレットに追跡を実装するには、例 8-7 に示すように、サーブレットの init() メソッドでファクトリ クラスを使って委託を作成します。
例 8-7 TraceMessageListenerFactory の使用
public final class TraceMessageListenerImpl extends SipServlet implements MessageListener {
private MessageListener delegate;
public void init() throws ServletException {
ServletContext sc = (ServletContext) getServletContext();
TraceMessageListenerFactory factory = (TraceMessageListenerFactory) sc.getAttribute(TraceMessageListenerFactory.TRACE_MESSAGE_LISTENER_FACTORY);
delegate = factory.createTraceMessageListener(getServletConfig());
}
public final void onRequest(SipServletRequest req, boolean incoming) {
delegate.onRequest(req,incoming);
}
public final void onResponse(SipServletResponse resp, boolean incoming) {
delegate.onResponse(resp,incoming);
}
}
リスナとロギング サーブレットが両方ともデプロイされている場合は、最初にリスナ クラスがロードされ、その後でサーブレットがロードされます。各ロギング サーブレットがデプロイされる順序は、Web アプリケーションのデプロイメント記述子で指定されているロード順序に従います。
一般に、プロダクション環境の Oracle WebLogic Communication Services では、サーバ負荷のピーク時も含めて常時、クライアントに対して非常に短い応答時間 (50 ミリ秒未満) で応答できる必要があります。短い応答時間を維持するための重要な要件の 1 つは、Oracle WebLogic Communication Services のエンジン層のインスタンスで使用する JVM のガベージ コレクション (GC) アルゴリズムを正しく選択し、かつ適切な状態にチューニングすることです。
一部のチューニング方式はガベージ コレクションの平均時間を最短にすることや完全なガベージ コレクションの実行頻度を最小に抑えることを目的として設計されていますが、これらの方式では、長短の GC 間隔を組み合わせて総合的に GC の影響を軽減する方針が採用されているので、結果的に 1 回または数回、非常に時間のかかる (数秒間に及ぶことが多い) ガベージ コレクションが発生することがあります。プロダクション環境の SIP Server では、応答時間の目標を維持するために、長い GC 間隔が一切発生しないようにする必要があります。
以下の節では、JRockit を使用する場合と Sun の JVM を使用する場合のそれぞれについて、応答時間が最短となる最適なパフォーマンスを一般的に実現できるチューニング方式を説明します。
Oracle WebLogic Communication Services エンジンとレプリカを起動するためにカスタムの起動スクリプトを使用する場合、次の節で説明されている、推奨される JVM オプションを含むようにスクリプトを編集します。
新しいドメインをコンフィグレーションする場合、コンフィグレーション ウィザードではデフォルトの起動スクリプトもインストールされます。これらのスクリプトはデフォルトで MIDDLEWARE_HOME/user_projects/domains/domain_name/bin のディレクトリにインストールされており、以下が含まれています。
startWebLogic.cmd、startWebLogic.sh — これらのスクリプトはドメインの管理サーバを起動します。
startManagedWebLogic.cmd、startManagedWebLogic.sh — これらのスクリプトはドメインで管理対象のエンジンとレプリカを起動します。
エンジンとレプリカを起動するために Oracle のインストールしたスクリプトを使用する場合、コマンド シェルで USER_MEM_ARGS の環境変数をはじめに設定することで JVM メモリ引数をオーバーライドすることができます。
|
注意 : USER_MEM_ARGS の環境変数を設定することで Oracle のインストールしたスクリプトで指定されたすべてのデフォルトの JVM メモリ引数をオーバーライドすることができます。常に使用する意向がある JVM メモリ引数の完全なリストに USER_MEM_ARGS を設定します。たとえば、デフォルトのヒープ領域 (-Xms、-Xmx) パラメータだけ変更する意向がある場合でも、Sun JVM を使用する場合、常に -XX:MaxPermSize=128m を USER_MEM_ARGS の値に追加します。 |
JRockit には、任意の時点の JVM ヒープを分析するために役立つ次のようなモニタリング ツールが用意されています。
JRockit Runtime Analyzer - ガベージ コレクションの実行時の動作および休止時間を確認できます。
JRockit スタック ダンプ - アプリケーションのスレッド アクティビティを調査して、トラブルシューティングまたはパフォーマンス向上、あるいはその両方に役立てることができます。
JVM の設定は、制御された環境でこれらのツールを使用することによって、その設定の効果や影響を事前に確認した上で、実際のプロダクション環境に適用してください。
以下の節では、JROCKIT JVM で使用する提案された起動時の JVM オプションについて説明します。確定的ガベージ コレクションで JRockit を使用すると (推奨)、節 8.8.3「Oracle JRockit Real Time の使用 (確定的ガベージ コレクション)」 で説明されたオプションを使用します。
非常に短い応答時間が確定的ガベージ コレクションを実装する JRockit Real Time の使用によって達成される。
レプリケートされたクラスタ コンフィグレーションのエンジン層サーバに以下の JVM 引数を使用することをお勧めします。
-Xms1024m -Xmx1024m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
|
注意 : コンフィグレーション ウィザードを使用して JRockit JVM による新しいドメインを作成する場合、上記の設定はデフォルトで$WLSS_HOME/common/bin/wlssCommenv.sh ファイルにコンフィグレーションします。
アロケーション インテンシブなアプリケーションに対して、 デプロイ済みアプリケーションで使用される実データの量に応じて、ヒープ サイズを調整します。開始点として、ヒープ サイズをアプリケーションが必要とする合計の 2 から 3 倍まで設定します。必要な合計の 3 倍に近い値は、通常、最良のパフォーマンスをもたらします。 |
レプリカ サーバのため、利用可能なメモリの容量を増大させます。
-Xms3072m -Xmx3072m -XgcPrio:deterministic -XpauseTarget=30ms -XXtlasize:min=8k -XXnosystemgc
これらの設定はヒープ サイズを固定して、確定的ガベージ コレクションとともにダイナミック ガベージ コレクタを有効にします。-XpauseTarget は、最大の休止時間を設定し、-XXtlasize=3k はスレッド ローカルの領域サイズを設定します。-XXnosystemgc で System.gc() アプリケーションの呼をガベージ コレクションの強制から防ぎます。
確定的ガベージ コレクションなしで Oracle JRockit を使用すると (プロダクション デプロイメントでは推奨されません)、世代の同時ガベージ コレクタを使用することで最適な応答時間パフォーマンスが取得されます。
エンジン層サーバの起動オプション例の一覧は以下のとおりです。
-Xms1024m -Xmx1024m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
|
注意 : デプロイ済みアプリケーションで使用される実データの量に応じて、ヒープ サイズを微調整します。 |
レプリカ サーバの起動オプション例の一覧は以下のとおりです。
-Xms3072m -Xmx3072m -Xgc:gencon -XXnosystemgc -XXtlasize:min=3k -XXkeeparearatio=0 -Xns:48m
Sun の JDK を使用する場合、ガベージ コレクションのパフォーマンス チューニングの目標は、完全なガベージ コレクションの 1 サイクルの実行に要する時間を短縮することです。完全なガベージ コレクションの発生頻度を最小限に抑えようとすると、多くの場合、結果的に、完了までに数秒を要する強制的なガベージ コレクション サイクルの発生を招くことになるので、JVM に対してそのようなチューニングを行うことは避けてください。
プロダクション サーバのライフタイムにおけるガベージ コレクション時間の短縮を実現する最も単純で信頼性の高い方法は、ヒープのサイズを固定してデフォルト コレクタと若い世代用の並行コレクタを使用することにより、新しい世代のサイズを最大でもヒープ全体の 1/3 までに制限することです。
ほとんどのエンジン層サーバには以下の JVM 設定例をお勧めします。
-server -Xmx1024m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
レプリカ サーバには、以下の設定例を使用します。
-server -Xmx3072m -XX:MaxPermSize=128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:MaxTenuringThreshold=0 -XX:SurvivorRatio=256 -XX:CMSInitiatingOccupancyFraction=60 -XX:+DisableExplicitGC
上記のオプションには、それぞれ次のような効果があります。
-XX:+UseTLAB - スレッド ローカルのオブジェクト割り当てブロックを使用します。これにより、共有ヒープ ロックに対する競合の発生が減少して、同時実行性が向上します。
-XX:+UseParNewGC - 同時 mark-and-sweep コレクタとともに、若い世代用の並行バージョンのコピー コレクタを使用します。これにより、使用可能なすべての CPU が並行して使用されるようになり、休止時間を最小限に抑えられます。この若い世代用のコレクタは、デフォルト コレクタおよび同時マーク アンド スイープ (CMS) コレクタのどちらとも併用できます。
-Xms, -Xmx - ヒープ サイズに境界を設け、ガベージ コレクションが予測どおりに実行される可能性を高めます。レプリカ サーバでヒープ サイズが制限されているので、完全な GC の実行時にも SIP の再送信が発生することがなくなります。-Xms ヒープの拡張を原因とする休止の発生を防ぐように起動時のヒープ サイズを設定します。
-XX:MaxTenuringThreshold=0 - すべての NewGC サイクルで NewSize の全体を使用できるようにして、寿命の長いオブジェクト (tenured object) の評価を不要にすることにより、休止時間を短縮します。より技術的に言えば、この設定は、生存しているすべてのオブジェクトを (コピーするのではなく) 古い世代に昇格させることを意味します。
-XX:SurvivorRatio=128 - 上記のゼロのしきい値の指定によって、生存しているすべてのオブジェクトを寿命の長いオブジェクトと見なすように設定した場合は、このように SurvivorRatio を高く設定することによって、実際には存在しない Survivor オブジェクトのために大きな領域が確保されることを防止できます。
Sun の JVM で乱数を生成するために使用されるライブラリは、UNIX プラットフォームではデフォルトで /dev/random に依存します。一部のオペレーティング システムでは、ホスト マシン上で一定量の「ノイズ」が生成されるのを待ってから結果を返すため、/dev/random が使用されていると、Oracle WebLogic Communication Services のプロセスがブロックされるおそれがあります。セキュリティ上は /dev/random の方がより安全ですが、JVM のデフォルトのコンフィグレーションで Oracle WebLogic Communication Services の起動時に遅延が発生する場合は、その代わりに /dev/urandom を使用することをお勧めします。
実際に使用しているオペレーティング システムでこの遅延の問題が発生するかどうかを確認するには、このファイルの一部分を表示する次のコマンドをシェル プロンプトから実行します。
head -n 1 /dev/random
テキスト エディタを使用して $JAVA_HOME/jre/lib/security/java.security ファイルを開きます。
以下の行を編集します。
securerandom.source=file:/dev/random
以下のように変更します。
securerandom.source=file:/dev/urandom
変更を保存して、テキスト エディタを終了します。
