10gリリース3（10.1.3.1.0）
B31836-02
 目次 |
 索引 |
| Oracle Application Server パフォーマンス・ガイド 10gリリース3（10.1.3.1.0） B31836-02 |
|
この章では、Oracle Application Serverの重要なチューニング分野について説明します。この章には、次の項が含まれています。
この項では、Oracle Application Serverの重要なパフォーマンス上の問題について説明するとともに、OC4J上で動作するJ2EEアプリケーションのチューニング方法について説明します。表3-1は、Oracle Application Serverのパフォーマンスに関するクイック・ガイドです。
| パフォーマンス分野 | 説明およびリファレンス |
|---|---|
|
十分なハードウェア・リソースの確保 |
Oracle Application Serverを使用するには、最小限のハードウェア要件を満たす必要があります。また、データベース層を含め、アプリケーション要件をサポートするハードウェア上で実行する必要があります。Oracle Application Serverのインストール要件の詳細は、各プラットフォームのインストレーション・ガイドの「要件」の章を参照してください。 ハードウェア・リソースが十分であるかどうかを調べるのに役立つプラットフォーム固有ツールの詳細は、「十分なハードウェア・リソースの確保」を参照してください。 |
|
十分なJavaヒープ・サイズの確保 |
J2EEアプリケーションのパフォーマンスを向上させるには、アプリケーションが実行されるJVMに十分なヒープ・サイズを設定する必要があります。J2EEアプリケーションを実行するOC4Jに十分なメモリーがない場合、限られたメモリーの管理に必要なオーバーヘッドによりパフォーマンスが低下します。 JVMヒープ・サイズのオプションの設定方法の詳細は、「OC4J用の十分なJavaヒープの確保」を参照してください。 |
|
JVMのガベージ・コレクションのチューニング |
J2EEアプリケーションのパフォーマンスを向上させ、同時に、アプリケーションのパフォーマンスがJVMのガベージ・コレクションによって低下しないように構成するには、ヒープ・サイズの管理が必要です。また、ガベージ・コレクションの頻度に影響するJVMオプションの設定が必要になる場合もあります。 ガベージ・コレクションの詳細は、「JVMのガベージ・コレクション・オプションのチューニング」を参照してください。 |
|
データベース接続の再利用 |
OC4Jデータソースでは、デフォルトでデータベース接続のプールが有効になっています。そのため、OC4Jは、新規接続の再確立が頻繁に行われないように、データベースの接続を管理します。Oracle Application Serverのデータソース機能には、データベース接続の維持数や維持時間を制御できるオプションがあります。 「データベース接続の再利用」を参照してください。 |
|
十分なHTTP接続の指定 |
HTTP接続数を指定して、同時実行性のレベルを設定して、Oracle HTTP Serverディレクティブをチューニングします。 「十分なOracle HTTP Server接続の指定」を参照してください。 |
|
JDBC文キャッシュ・オプションの有効化 |
カーソルを繰返し作成したり、文を繰り返し解析および作成することに起因するオーバーヘッドを軽減するために、文キャッシュを有効にすることで、データベース層を使用するアプリケーションのパフォーマンスを向上させることができます。 「データソースに対する文キャッシュの有効化」を参照してください。 |
|
データベースのチューニングの適正な実行 |
アプリケーションがデータベースにアクセスする場合は、アプリケーション要件がサポートされるよう、データベースを適切に構成する必要があります。 「データベース・チューニングの検証」を参照してください。 |
|
ロギング・レベルの検証 |
ロギング・レベルは、デフォルトのロギング・レベルである「INFO」よりも高く設定しないようにする必要があります。ロギングの設定がデフォルトと一致していない場合は、デフォルトにリセットし、最良のパフォーマンスが得られるようにします。 「ロギング・レベルの検証」を参照してください。 |
|
EJBインスタンスの再利用 |
インスタンスの作成と再利用に関連するEJBオプションを設定し、EJBのパフォーマンスを向上させます。 「EJBインスタンスの再利用」を参照してください。 |
ユーザー数とアプリケーション要件をサポートする十分なCPU、メモリーおよびネットワーク・リソースをOracle Application Serverインストール用に確保することは、最も重要なパフォーマンス分野です。リソースの利用状況を一定期間監視して、使用が一時的にピークに達することがあるのか、それともリソースが常に飽和状態にあるのかを調べる必要があります。また、サイトで実行されるアプリケーションに許容できるレスポンス時間とスループットを、ピーク時と平常時の両方で定義する必要があります。さらには、通常の負荷でアプリケーションが実行されているときにシステムをチェックして、CPU、メモリー、ディスク、ネットワーク・パフォーマンスなどのオペレーティング・システム統計を監視し、飽和状態のハードウェア・リソースがあるかどうかを調べます。
CPU、メモリーおよびディスク・パフォーマンスをチェックするには、次のコマンドを使用します。
Linuxシステムでは、sarまたはmpstatコマンドを使用します。
Windowsシステムでは、perfmonコマンドを使用します。
ネットワーク・パフォーマンスをチェックするには、次のコマンドを使用します。
LinuxおよびWindowsシステム:
% netstat
Windowsシステムでは、Windowsのタスク マネージャを使用して、ネットワーク・パフォーマンスをチェックすることもできます。
飽和状態になっているハードウェア・リソースが1つでもある場合は、次に示す原因の1つ以上が該当する可能性があります。
リソースが常に飽和状態の場合は、負荷を軽減するか、リソースの追加が必要です。通信のピーク時、レスポンス時間が許容範囲を超える場合は、やはりリソースを追加します。または、バッチ処理やバックグラウンド操作を非ピーク時にスケジュール変更するなど、ピーク時の負荷を軽減できるようなスケジュール変更が可能でないかどうかを調べます。Oracle Application Serverには、リソースの同時使用を制御する各種メカニズムが用意されており、これによって通信の一時的な急増を制限できます。ただし、常に飽和状態にあるシステムでは、これらのメカニズムは一時的な解決策にしかなりません。
システムに十分なメモリーがあり、アプリケーションがメモリーを集中的に使用する場合、JVMヒープ・サイズのデフォルト値を大きくします。必要なヒープ量はアプリケーションおよび使用可能なメモリー量によって異なりますが、通常のOC4Jサーバー・アプリケーションでは、メモリーが十分である場合、初期ヒープ・サイズを512MB以上に設定することをお薦めします。
初期ヒープ・サイズを最大のヒープ・サイズと等しくすることにより、パフォーマンスを向上させることができます。
OC4Jインスタンスのヒープ・サイズ値を変更する手順は次のとおりです。
これによって、次の項のJVMオプションが指定され、OC4Jインスタンス内のOC4Jプロセスに割り当てられるヒープ・サイズが変更されます。
Oracle Application Serverトポロジ内の同じシステム上に複数のJVMがある場合、パフォーマンスを最大にするには、アプリケーションの要件を満たす最大ヒープ・サイズを設定し、システム上で動作するすべてのJVMが消費する合計メモリー量がシステムのメモリー容量を超えないようにします。
JVMのガベージ・コレクションは負荷のかかる操作で、アプリケーションのパフォーマンスに影響します。非効率的なガベージ・コレクションは、アプリケーションのパフォーマンスを大幅に低下させる可能性があります。そのため、アプリケーションでオブジェクトがどのように作成および破棄されるかを理解しておくことが重要です。
JVMのガベージ・コレクション・オプションをチューニングするには、ガベージ・コレクションのデータを解析し、ガベージ・コレクションの頻度とタイプ、メモリー・プールのサイズ、およびガベージ・コレクションに要した時間を確認する必要があります。
アプリケーションに必要なメモリーを調べるには、次のツールを使用して、JVMガベージ・コレクションとメモリー・プール・サイズを監視します。
-verbose:gc -XX:+PrintGCDetails
「Full GC」行を調べ、負荷のかかるコレクションの発生頻度を確認します。
jstatツール
visualgcツール
-XX:+AggressiveHeap JVMオプションを設定して、VMの内部パラメータをチューニングします。また、「OC4J用の十分なJavaヒープの確保」の説明に従って、ヒープの合計サイズを増やし、「Full GC」ガベージ・コレクションに起因するオーバーヘッドを軽減します。-XX:+AggressiveHeapオプションを使用すると、VMの内部パラメータが、メモリーを集中的に使用する長時間実行されるワークロードに対して最適化されます。このオプションは、コマンドラインのヒープ・サイズ設定オプションの-Xmsおよび-Xmxの後に指定します。Oracle Application Server管理環境でのJavaコマンドライン・オプションの設定方法の詳細は、「OC4J用の十分なJavaヒープの確保」を参照してください（-XX:+AggressiveHeapを使用しないよう説明している、Sun社の古いバージョンのドキュメントは無視してください）。
アプリケーションでガベージ・コレクション（パフォーマンスを低下させる原因となる）が明示的に使用されているかどうかを調べるには、-XX:+DisableExplicitGCオプションを設定します。このデバッグ・オプションを設定すると、ガベージ・コレクションは明示的に行われなくなり、アプリケーションでsystem.gc()コールが使用されなくなります。アプリケーションがガベージ・コレクションを明示的に起動していると思われる場合は、このパラメータを設定して、ガベージ・コレクションの動作の違いを観察します。アプリケーションでsystem.gc()が明示的にコールされていることが判明した場合は、それが起動される理由とコールを無効にした場合の影響についてアプリケーション開発者と検討します。アプリケーション開発者は、ファイナライザを起動する目的でsystem.gc()コールを使用している場合があります。この方法は推奨されておらず、想定外の動作の原因となります。
JVMコマンドライン・オプションを変更する手順は次のとおりです。
データベース接続の作成と再作成のオーバーヘッドを軽減することでアプリケーションのパフォーマンスを改善するには、接続プールのmin-connections属性を指定して接続プールに維持する最小接続数を設定します。
デフォルトでは、min-connectionsの値は0です。最高のパフォーマンスを得るには、min-connectionsの値を0以外に設定します。min-connectionsが0以外の値に設定されている場合は、その数の接続が維持されます。接続は使用されていないときでもOC4Jによって維持され、inactivity-timeoutに設定されている値に達してもタイムアウトしません。min-connections属性を設定しても、OC4Jによって起動時に接続が事前作成されるわけではありません。接続プールの初期作成時または再初期化時に作成される接続数を設定するには、initial-limit属性を指定します。initial-limit属性はmin-connections属性と同じ値に設定することをお薦めします。
min-connectionsの設定値がmax-connectionsよりも小さい場合は、inactivity-timeoutを設定して、非アクティブな接続状態が妥当な時間継続した場合にのみ接続がタイムアウトするようにする必要があります。接続プールのinactivity-timeoutには、接続が閉じられるまで未使用の接続をキャッシュする時間を秒単位で指定します。
パフォーマンスを向上させるには、接続プールのinactivity-timeoutを、J2EEアプリケーションの実行中に接続の切断や再取得が生じないような値に設定します。inactivity-timeoutのデフォルト値は60秒です。通常、この値は頻繁にアクセスされるアプリケーションには短すぎるため、リクエスト間に非アクティブな状態が生じる可能性があります。ほとんどのアプリケーションのパフォーマンス向上には、inactivity-timeoutの値として、120秒の設定をお薦めします。
デフォルトのinactivity-timeout値が低すぎるかどうかを判断するには、システムを監視します。データベース接続数が増加した後アイドル時間中に減少し、その後再び増加する場合は、inactivity-timeoutまたはmin-connectionsのいずれかの値を大きくします。
データベース接続の再利用に関する注意事項:
同時にアクティブになる可能性があるすべての接続プールのmin-connectionsに対する設定値の合計、およびデータベースの全データソースに対する必要最大同時実行数。
min-connectionsが0以外の値に設定されている場合は、その数の接続が維持されます。接続は使用されていないときでもOC4Jによって維持され、inactivity-timeoutに設定されている値に達してもタイムアウトしません。指定された接続が開かれている場合は、OC4Jを停止するかリフレッシュ操作を実行して、接続を閉じる必要があります。リフレッシュ機能は、Application Server Controlの「JDBCリソース」ページの「接続プール」領域にあります。リフレッシュ操作を実行するには、「接続プールのリフレッシュ」フィールドにあるアイコンをクリックします。
Oracle HTTP Server MaxClientsディレクティブは、Webサーバーに同時に接続できるクライアント数、ひいてはhttpdプロセスの数を制限します。
Windowsでは、類似パラメータとしてThreadsPerChildがあります。Oc4jCacheSizeディレクティブは、mod_oc4jがOC4J JVMごとに維持するアイドル接続の最大数を指定します（Windowsにのみ該当）。
MaxClients、ThreadsPerChildおよびOc4jCacheSizeディレクティブを使用して、Oracle HTTP ServerからOC4Jインスタンスへの着信接続を制限できます。この項には、次の項目が含まれています。
MaxClientsディレクティブは、httpd.confファイルで構成でき、最大値は8Kです（デフォルト値は150）。システム・リソースが飽和状態でなく、HTTPの同時接続ユーザー数が150を超えている場合、MaxClientsを増やしサーバーの同時実行性を向上させると、パフォーマンスを改善できます。システムの利用状況がフル（目安は85%）になるまで、MaxClientsを増やします。
システム・リソースが飽和状態のときにMaxClientsを増やしても、パフォーマンスは改善されません。この場合、サーバーへの同時リクエスト数に対するスロットルとして、MaxClients設定を小さくします。
サーバーで永続的な接続を処理している場合は、アクティブな接続とアイドルな接続の両方を処理する十分な同時httpdサーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxClientsを指定するとき、アイドル状態の永続的なhttpd接続もhttpdプロセスを消費することを考慮に入れる必要があります。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。永続的（KeepAlive）なHTTP接続は、リクエストの処理中でないときでも、接続期間中は、httpd子プロセス、つまりスレッドを消費します。
十分なリソースがある場合は、KeepAliveを有効にすることをお薦めします。永続的な接続を使用することで、パフォーマンスが向上し、HTTP接続の再確立によるCPUリソースの浪費が回避されます。通常の場合、KeepAliveパラメータの変更は不要です。
使用可能なhttpdプロセスがない場合、接続リクエストはプロセスが使用可能になるまでTCP/IPシステムのキューに入れられ、しばらくするとクライアントにより接続が終了されます。
ThreadsPerChildディレクティブは、httpd.confファイルで構成でき、最大値は8Kです（デフォルト値は150）。WindowsシステムのThreadsPerChildパラメータは、UNIXシステムのMaxClientsパラメータと同様に動作します。
Oc4jCacheSizeディレクティブでは、mod_oc4jがOC4J JVMごとに維持するアイドル接続の最大数を指定します。Windowsでのみ、このディレクティブのデフォルト値を変更すると効果的な場合があります。
UNIXシステムでは、Oracle HTTP Serverの各プロセスはシングル・スレッドのため、意味のある値はデフォルト値の1とゼロ（0）のみです。この値がゼロ（0）の場合、Oracle HTTP Serverは接続を維持する必要はなく、リクエストごとに新しい接続を開く必要があることを指定します。各プロセスはシングル・スレッドであるため、複数の接続は不要であり、値が1より大きくてもUNIXシステムに与える影響は値が1の場合と同じです。UNIXシステムで最高のパフォーマンスを得るには、Oc4jCacheSizeのデフォルト値を変更しないでください。
Windowsシステムでは、デフォルトのOc4jCacheSize値はThreadsPerChildの値の75%で、その接続キャッシュが子プロセス内のスレッド間で共有されます。Oracle HTTP Serverに静的コンテンツとOC4Jリクエストの両方の負荷がかかる場合は、このデフォルト値で十分です。ユーザーの負荷がすべてのOC4Jリクエストである場合、つまりOracle HTTP Serverがコンテンツをほとんど、あるいはまったく提供せず、OC4Jのフロント・エンドとしての役割しか果たさない場合、ThreadsPerChildと等しいOc4jCacheSizeを設定することをお薦めします。この設定では、必要に応じてスレッドごとに専用の接続が用意され、パフォーマンスが最高になります。
num-cached-statements属性を0よりも大きな値に設定（デフォルト値は0で、文キャッシュは無効）することで、カーソルを繰返し作成したり、文を繰り返し解析および作成することに起因するオーバーヘッドを軽減する、文キャッシュを有効にできます。num-cached-statementsに設定する値は、アプリケーションで使用されているSQL文の数とします。
Oracle Application Serverで、データベースを使用するアプリケーションのパフォーマンスを最適にするには、アクセスするデータベース表を設計する際に、パフォーマンスを考慮します。さらに、システムを効果的に利用していることを確認するためにデータベース・サーバーを監視し、チューニングする必要があります。
この項には、次の項目が含まれています。
表3-2に、init.oraデータベース初期化パラメータのチューニング情報を示します。
データベースI/Oのロード・バランシングの管理は重要なタスクです。しかし、REDOログのオプションをチューニングすることによってOracle Application Server環境で実行されているアプリケーションのパフォーマンスを改善したり、場合によっては、REDOログを別のディスクへ移動することでI/Oスループットを大幅に向上させることができます。
データベース・ライター・プロセスとアーカイバ・プロセスの動作がREDOログのサイズに依存するため、REDOログ・ファイルのサイズはパフォーマンスにも影響を与える可能性があります。一般的に、REDOログ・ファイルのサイズが大きいほどチェックポイント・アクティビティが減り、パフォーマンスは向上します。REDOログ・ファイルについて推奨されるサイズを特定することはできませんが、REDOログ・ファイルは、100MBから数GBの範囲に設定することが適切であると考えられます。オンラインREDOログ・ファイルのサイズは、システムで生成されるREDOの大きさに従って設定します。おおよその目安としては、多くても20分に1回ログ・スイッチを実行します。初期化パラメータLOG_CHECKPOINTS_TO_ALERT = trueを設定して、アラート・ファイルにチェックポイントの時間を書き込みます。
必要なREDOログ・ファイルの完全なセットは、データベース作成時に作成できます。作成後、REDOログ・ファイルのサイズは変更できません。ただし、新たに大きなサイズのファイルを後から追加することはできます。その際に元の小さいファイルを削除できます。
永続表領域には、自動セグメント領域管理を使用することをお薦めします。こうした表領域は、ビットマップ表領域とも呼ばれ、ビットマップ・セグメント領域管理によってローカルで管理されます。
下位互換の理由から、ローカル表領域のデフォルトのセグメント領域管理モードはMANUALです。
アプリケーションとサーバーのロギング・レベルが適正であること、またデバッグ・プロパティや他のアプリケーション・レベルのデバッグ・フラグのレベルが適正、または無効に設定されていることを確認する必要があります。Oracle Application Server OC4Jのログ出力レベルを、「INFO」レベルのログ・メッセージに設定します（詳細な診断メッセージが出力される「FINE」や「トレース」などのレベルには設定しないでください）。
Application Server Controlコンソールを使用してOC4Jコンポーネントのログ出力を構成するには、OC4Jホーム・ページから次の手順を実行します。
この項では、インスタンスの作成と再利用によってEJBのパフォーマンスを向上させるEJBチューニング・オプションについて説明します。これらのオプションはOC4J固有で、すべてのタイプのEJB（ステートフル・セッションのEJBを除く）に適用できます。これらのオプションを構成するには、orion-ejb-jar.xmlファイルで属性を設定します。
min-instances属性には、インスタンス化またはプールされたまま保持されるBean実装インスタンスの最小数を指定します。デフォルト値は0です。最高のパフォーマンスを得るには、min-instancesの値を0以外に設定します。min-instancesの値が0よりも大きい場合は、インスタンスが使用されていないときでも、OC4Jによってmin-instancesの数のインスタンスがプールに保持されます。min-instancesを超えるインスタンスは、pool-cache-timeoutに指定されたタイムアウトの経過後、プールから削除されます。pool-cache-timeoutはキャッシュの有効期限を示し、このタイムアウト・ウィンドウ期間内にアクセスされなかったすべてのBeanインスタンスが削除されます。たとえば、デフォルト値のpool-cache-timeoutでは、60秒間アクセスされなかったすべてのBeanがプールから削除され、アクティブまたは最近使用されたBeanがプールに維持されます。
pool-cache-timeoutのデフォルト値は60秒で、通常、これは頻繁にアクセスされるEJBには低すぎます。pool-cache-timeoutが0またはマイナスの場合、pool-cache-timeoutは無効になり、Beanはプールから削除されません。
パフォーマンスをチューニングするには、pool-cache-timeoutを大きな値に設定して、Beanがプールから削除される頻度を小さくします。pool-cache-timeoutは、J2EEアプリケーションの実行中にインスタンスの破棄と再作成が生じないような、十分に大きな値に設定する必要があります。
この項では、特定の使用方法および環境下で、パフォーマンスの向上に役立つパフォーマンス分野について説明します。
この項には、次の項目が含まれています。
Oracle Application Serverでは、特定の使用要件に合せて、システムの複数の層で同時実行性を制限できます。HTTP接続の制御以外に、製品の他のレベルでも同時実行性を制御でき、様々な使用要件に対応できます。
この項には、次の項目が含まれています。
OC4Jでは、この後に説明するスレッド・プールがデフォルトで作成されます。新規スレッドは必要になった時点で作成され、プールに追加されます。
rmi requestスレッド・プールが未構成の場合）およびRMI接続（rmi connectionスレッド・プールが未構成の場合）を処理するスレッド・プール。デフォルトの動作では、スレッド数は最大1024で、要求に応じて作成されます。
OC4Jプロセスが利用または再利用するスレッドは、スレッド・プールによって作成および保持されます。一般的な使用例では、デフォルト構成のスレッド・プール管理で十分です。スレッド・プールにある既存のスレッドを再利用することで、パフォーマンスが向上し、JVMおよびオペレーティング・システムに対する負荷が軽減されます。
一部のケースでは、スレッド・プールの管理オプションを指定し、デフォルトの動作を変更することでパフォーマンスが向上することがあります。次に、そうした状況を示します。
max-connectionsパラメータを使用してデータベース接続を制限できます）。
次の状況では、スレッド・プールをチューニングしても、パフォーマンスは向上しません。
MaxClientsディレクティブによってHTTPサーバー・レベルで同時実行性が制御されている場合や、データソースのmax-connections属性によってデータベース接続の同時実行性が制御されている場合。この項では、スレッド・プールの構成オプションを管理および使用する方法について説明します。
アプリケーション・サーバーのスレッド・プールは、次の方法で管理できます。
server.xmlの<thread-pool>要素に、適切な属性を追加します。次に例を示します。
<thread-pool name="http" min="120" max="120" queue="240" ¥>
ThreadPool MBeanの属性を更新します。
スレッド・プール・オプションの指定に関する注意事項:
min値（最小プール・サイズ）をmax値（最大プール・サイズ）と同じに設定することをお薦めします。minとmaxが同じとき、queueは、想定されるリクエストの最大同時実行数と等しい値に設定します。たとえば、使用するOracle HTTP ServerにOC4Jインスタンスが1つあり直接的なRMI接続を使用しない場合、MaxClientsの値は最大同時実行数を表します。注意: MaxClientsを非常に大きな値に設定する場合、queueのサイズは300以下程度で十分です。スレッド・プールおよびキューの監視方法は、「スレッド・プールのパフォーマンスの検証と監視」を参照してください。スレッド数の設定は小さな値から始めることをお薦めします。たとえば、基本インストール・オプションのOracle Application Server 10gリリース3（10.1.3.1.0）では、最初はminとmaxを80から100の範囲の値に設定し、この値で問題がないかどうかパフォーマンスを監視します。スタンドアロンのOC4J構成では、minとmaxを15から40の範囲の値に設定し、この値で問題がないかどうかパフォーマンスを監視します。サイトに使用可能なCPUおよびメモリー・リソースが十分にあり、同時リクエスト数が現行のスレッド数設定よりも大きい場合は、スレッド数を増やします。これでシステムのリソースが飽和状態になる場合は、スレッド数を減らします。適切なスレッド設定は、アプリケーションの特性によって決まります。
min値とmax値を同じにすることをお薦めします。ただし、max値を大きくしてピーク時の一時的な通信に対応する場合は、最小数のスレッドが作成されるまで、リクエストごとに1つのスレッドが追加されます。最小数のスレッドが作成された後は、キューが一杯になるまで、新規スレッドは作成されません。OC4Jでは、キューが一杯にならないかぎり、スレッド数を最小かまたはそれに近い数で維持します。min値の設定をmax値よりも小さくした場合は、キュー・サイズを小さくしておくことをお薦めします。queueのデフォルト値は0です。これは、リクエストはキューされず、スレッド数が指定されたmax値未満の場合に新しいスレッドが作成されることを意味します。スレッドが最小値を超えないようであれば、キュー・サイズを減らす必要があります。OC4Jでは、RMI接続スレッド用のスレッド・プールがサポートされます。デフォルトでは、RMI接続スレッドは、httpという名前のアプリケーション・サーバーのスレッド・プールから割り当てられます。RMI接続スレッド・プールを使用すると、専用のスレッド・プールが作成され、そのスレッドによってRMI接続に対するブロック読取りが実行されます。RMI接続スレッド・プールを定義すると、RMI接続に独自の制限が課され、httpスレッド・プールから割り当てられなくなります。RMI接続スレッド・プールを指定するには、server.xmlの<thread-pool>要素にrmi connectionという名前を使用し、アプリケーション作業用のスレッドから長時間存続する可能性がある接続スレッドを分離します。この構成によって、残りの作業用スレッドが、長時間存続するRMI接続に割り当てられることなく、作業用に確保されます。
RMI接続スレッド・プールを定義すると、RMI接続の作業はhttpスレッド・プールのスレッドから分離実行されます。また、RMIリクエスト・スレッド・プールも指定されている場合は、RMI接続の作業はRMIリクエスト・スレッド・プールのスレッドから分離実行されます（RMIリクエスト・スレッド・プールは、server.xmlの<thread-pool>要素に名前rmi requestを指定して構成する）。RMIリクエスト・スレッド・プールは、RMI接続に関連付けられている作業を、他の作業（HTTPリクエストなど）から分離して制御する必要がある場合に指定します。
10gリリース3（10.1.3）から、MDBタイプのEJBでは、JMSリソース・アダプタにレシーバ・スレッドが使用されるようになりました。OC4Jは、これらのスレッドと他のJCAリソース・アダプタ用のスレッドを、作業マネージャのスレッド・プール（jcaスレッド・プール）から割り当てます。この場合、レシーバ・スレッドによってシステム全体の同時実行性が制御されることを考慮に入れる必要があります。jcaスレッド・プールはデフォルト設定のままにすることをお薦めします（デフォルトでは、JCA作業マネージャ・スレッドは最大2040に制限される）。EJB MDBの同時実行性を制御する場合は、JMS ReceiverThreadsに最大値を使用します。システム全体の同時実行性に対する制限は、OC4Jにデプロイされたアプリケーションに構成されているすべてのMDB receiverThreadsの合計またはjcaのmaxスレッドの少ないほうを、httpスレッド・プールに指定されたmaxスレッドに加算したものになります（RMI接続のmaxスレッドおよびRMIリクエストのmaxスレッドが構成されている場合は、それらも加算する）。
システムのOC4Jスレッドの使用状況は、Application Server Controlコンソールの「現在のプールサイズ」および「現在のキュー・サイズ」メトリックを使用して監視できます。これらのメトリックにアクセスするには、OC4Jホーム・ページの「管理」サブタブ→「スレッド・プール構成」タスクをクリックします（図3-1を参照）。「現在のプールサイズ」には、プール内にある現行のスレッド数が表示されます。「現在のキュー・サイズ」には、スレッドが使用可能になるのをキュー内で待機している現行のリクエスト数が表示されます。設定はデフォルトから開始して、システムの動作を監視することをお薦めします。また、スレッド・プールまたはキュー・サイズの制限をインスタンスに対して変更した場合も、これらのメトリックを監視してください。
データベースを使用するアプリケーションでは、データソースに関連付ける接続プールの接続数を制限することでパフォーマンスを改善できます。データベースが着信リクエストで飽和状態にならないようにOracle Application Serverからデータベースへのリクエストを制限したり、データベース・アクセスがOracle Application Server層のリソースに負荷をかけすぎないようにデータベース・リクエストを制限するには、max-connections属性を使用します。
接続プールのmax-connections属性は、接続プールに許可される最大接続数を指定します。デフォルトでは、max-connectionsの値は-1（無制限）に設定されています。最高のパフォーマンスを得るには、max-connectionsの値を、各自のデータベースのパフォーマンス特性に適した数に設定する必要があります。
開いているデータベース接続の合計数を、データベースが処理できる数に制限することは、チューニングの際の重要なポイントです。少なくとも、データベースにアクセスするすべてのアプリケーションで指定されている、すべてのデータソースmax-connectionsオプションの値の合計と同じ数のオープン接続を許可するように、データベースが構成されているかどうかを確認する必要があります。
EJBインスタンスの数を制限してメモリーの使用を軽減したり、同時実行性を制御してEJBが使用するリソース（データソースなど）に対する競合を減らすことが必要になる場合があります。
max-instancesパラメータは、メモリー内で許容される、インスタンス化またはプールされたBeanインスタンスの数を指定します。
max-instances値に到達し新しいEJBがリクエストされると、コンテナはcall-timeout属性に設定されているミリ秒数だけ待機し、プール内のBeanインスタンスが使用可能になるかどうかを確認します。プール内のBeanインスタンスが使用可能にならない場合は、クライアントにTimeoutExpiredExceptionがスローされます。
max-instances値に到達すると、コンテナはメモリーの最も古いBeanインスタンスの非アクティブ化を試みます。非アクティブ化に失敗した場合、TimeoutExpiredExceptionがクライアントにスローされる前に、コンテナは、call-timeout属性に設定されているミリ秒数だけ待機し、非アクティブ化、remove()メソッドの使用、またはBeanの期限切れによってBeanインスタンスがメモリーから削除されるかどうかを調べます。
Beanインスタンスの数を無制限に許可するには、max-instances = 0を指定します（デフォルト値は0）。
インスタンスのプーリングを無効にするには、max-instancesを< 0（-1など）に設定します。この場合は、EJBコールを開始すると、OC4Jによって、新しいBeanインスタンスまたはコンテキストが作成されます。そしてコールの終了時に、コンテキストが解放され、存在しない状態にインスタンスがスローされます。
例外のcom.evermind.server.ejb.TimeoutExpiredException: timeout expired waiting for an instanceが、利用可能なEJBインスタンスがない場合に発生します。この問題を回避するには、max-instancesおよびcall-timeoutパラメータを適切に設定します。
リモートEJBクライアント接続を制限するには、httpスレッド・プールのmax値を変更し全スレッドに対して制限を指定するか、または着信EJBクライアントにサービスを提供するスレッドの最大数を制御するスレッド・プール機能を使用できます。デフォルトでは、リモートEJBクライアント接続用のスレッドはhttpスレッド・プールから割り当てられます。RMI接続スレッド・プールの使用が必要なときは、server.xmlの<thread-pool>要素に名前rmi connectionを構成します。RMI接続スレッド・プールのmax値を設定することで、リモートEJBクライアント接続を制限できます。
Oracle Application Serverには、J2EEアプリケーションに対する負荷と着信リクエストを複数のアプリケーション・サーバー・インスタンスに分散するロード・バランシング機能が組み込まれています。この機能によって、通常、スループットが向上し、レスポンス時間が短縮されます。アプリケーション・サーバー・インスタンスが複数あるとき、ロード・バランシング機能を使用すると、リクエストが複数のアプリケーション・サーバー・インスタンス間で振り分けられ、パフォーマンスが向上します。また、複数のホストで複数のアプリケーション・サーバー・インスタンスを実行することで、高可用性とフェイルオーバーの要件に対応できます。
この項には、次の項目が含まれています。
この項には、次の項目が含まれています。
使用可能なCPUに対するOC4Jプロセスの最適比率の決定は、実行するアプリケーションの特性、OC4J構成、ハードウェア構成、予期される着信リクエストの種類と数によって異なります。CPUが少数のハードウェア構成では、1つのOC4Jインスタンスで十分です。
システム・リソースの許容範囲を超えてOC4Jインスタンスを追加しても、パフォーマンスは向上しません。たとえば、1つのOC4JインスタンスでシステムのCPUリソースが使い尽くされている場合、OC4Jインスタンスを追加してもパフォーマンスが向上しないばかりか、逆にそれを低下させます。最初はOC4Jインスタンスを1つのみ構成し、OC4Jインスタンスを追加するたびにパフォーマンスが向上したか測定する方法を採用することをお薦めします。
要件が異なる各アプリケーションを別々のOC4Jインスタンスで動作するようにパーティション化すると、アプリケーションのパフォーマンスが向上する場合があります。この場合は、特定のOC4Jインスタンスが特定のアプリケーションにサービスを提供するように構成します。それぞれのOC4Jインスタンスにアプリケーションをデプロイした後、パフォーマンスを監視して、全体的なスループットの増加およびレスポンス時間の短縮を確認します。
Oracle Application Server環境では、Oracle HTTP Serverはmod_oc4jを使用して使用可能なOC4Jインスタンス間でリクエストをロード・バランシングします。この環境でmod_oc4j構成オプションの適切なロード・バランシング・ポリシーを選択し、パフォーマンスを向上させます。デフォルトでは、リクエストはラウンド・ロビン・アルゴリズムを使用してルーティングされます。
多くのサイトで、Oracle Application ServerではOracle HTTP Serverモジュールのmod_oc4jを使用して、着信したステートレスHTTPリクエストのロード・バランシングが実装されます。mod_oc4jの適切なロード・バランシング・ポリシーを選択することで、サイトのパフォーマンスを改善できます。
mod_oc4jモジュールでは、次のような構成可能なロード・バランシング・ポリシーがサポートされています。
mod_oc4jのデフォルトのロード・バランシング・ポリシー）
localオプションを使用したローカル・アフィニティによるラウンド・ロビン・ルーティングまたはランダム・ルーティング
weightedオプションを使用したホストレベルの重み付けによるラウンド・ロビン・ルーティングまたはランダム・ルーティングmod_oc4jを使用したロード・バランシングにおける推奨事項:
たとえば、Oracle HTTP Serverでmod_oc4jモジュールを構成して、Host_Aに対するルーティングの重み付けが3、Host_Bに対するルーティングの重み付けが1のラウンド・ロビン・ポリシーを指定するには、mod_oc4j.confに次のディレクティブを追加します。
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingWeight Host_A 3
この例では、ルーティングの重み付けのデフォルト値は1であるため、Host_Bにルーティングの重み付けを指定する必要はありません。
mod_oc4jを設定します。これによって、通常はパフォーマンスが向上します。ローカルのOC4Jプロセスが使用できない場合、mod_oc4jは、使用可能なリモートのOC4Jプロセスのリストからプロセスを選択します。たとえば、ローカル・アフィニティ・オプションを使用したラウンド・ロビン・ポリシーを選択するには、mod_oc4j.confで次のディレクティブを指定します。
Oc4jSelectMethod roundrobin:local
EJBアプリケーションを複数のOC4Jインスタンスにデプロイすると、EJBのクライアント側アプリケーションのリクエストに対するロード・バランシングは、使用可能なOC4Jインスタンス間でなされます。ロード・バランシングを使用するには、クライアント側のアプリケーションでロード・バランシングを使用するようにJNDIプロパティを構成します。一部のクライアントのパフォーマンスの改善には、oracle.j2ee.rmi.loadBalance=contextを設定する必要があります。これによって、クライアント全体に対して1度のみロード・バランシングが行われるのではなく、initialcontextコールのたびにロード・バランシングが行われるようになります。
Sun 5.0 JVMでは、負荷が非常にかかっている一部の状況で、アプリケーションの同期によってスレッド不足が生じる場合があります。これは、アプリケーションのリクエストが停止または長時間経過後にタイムアウトする原因となります。
10gリリース3（10.1.3.1.0）では、管理OC4Jに対して、パラメータ-XX:AppendRatio=3がデフォルトで指定されます。スタンドアロンのOC4Jで、インストールにこの問題があると思われる場合は、JDKパラメータの-XX:AppendRatio=3を設定し問題を回避することをお薦めします。
|
 Copyright © 2001, 2008, Oracle. All Rights Reserved. |
|