| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース1（11.1.1） B61006-01 |
|
 戻る |
 次へ |
この章では、Oracle Fusion Middlewareの主なチューニング分野について説明します。取り上げるのは、Oracle Fusion Middlewareの重要なパフォーマンス分野です。この章は、J2EEアプリケーションのチューニングにおけるクイック・スタート・ガイドとなります。この章の内容は次のとおりです。
パフォーマンス・チューニングの最も難しい面の1つは、どこから始めればよいかを知ることです。この章は、Oracle Fusion Middlewareアプリケーションのパフォーマンス・チューニングにおけるクイック・スタート・ガイドの役割を果します。
表2-1は、Oracle Fusion Middlewareのパフォーマンスに関する一般的な考慮事項をリストにまとめたものです。このリストは、パフォーマンス・チューニングを始めるうえで有効なツールとなりますが、チューニングが必要な分野をすべて網羅してはいません。アプリケーションにおけるパフォーマンスの問題を個別に監視、追跡し、どこをチューニングすればパフォーマンスが向上するかを把握する必要があります。詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。
表2-1 Oracle Fusion Middlewareの主なパフォーマンス分野
| パフォーマンス分野 | 説明と参照先 |
|---|---|
|
ハードウェア・リソース |
パフォーマンスを最大化するために、アプリケーションのリソース要件と同等またはそれ以上のハードウェア・リソースがあることを確認します。 ハードウェア・リソースが十分かどうかを判断する方法の詳細は、2.2項「十分なハードウェア・リソースがあることの確認」を参照してください。 |
|
オペレーティング・システム |
各オペレーティング・システムには、監視用の便利なネイティブ・ツールおよびユーティリティが用意されています。 2.3項「オペレーティング・システムのチューニング」を参照してください。 |
|
Java仮想マシン（JVM） |
この項では、ベスト・プラクティスについて説明し、JVMのチューニングおよびJ2EEアプリケーションのパフォーマンス向上に役立つ実用的なヒントを示します。ヒープ・サイズおよびJVMガベージ・コレクション関連のオプションについても説明します。 2.4項「Java仮想マシン（JVM）のチューニング」を参照してください。 |
|
データベース |
データベースにアクセスするアプリケーションの場合は、データベースがアプリケーションの要件に合せて正しく構成されていることを確認します。 詳細は、2.6項「データベース・パラメータのチューニング」を参照してください。 |
|
WebLogic Server |
Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、2.5項「WebLogic Serverのチューニング」を参照してください。 |
|
データベース接続 |
接続を再利用するための接続プーリングは、チューニングの際の重要な考慮事項です。 2.7項「データベース接続の再利用」を参照してください。 |
|
データ・ソースの文キャッシュ |
データベースを使用するアプリケーションの場合は、文キャッシュを正しく構成することで、繰り返し実行される文の解析および作成がパフォーマンスに与える影響を軽減できます。 2.8項「データ・ソースの文キャッシュの有効化」を参照してください。 |
|
Oracle HTTP Server |
Oracle HTTP Serverディレクティブをチューニングし、HTTP接続数を指定して同時実行性のレベルを設定します。 2.9項「同時実行性の制御」を参照してください。 |
|
同時実行性 |
この項では、Oracle Fusion Middlewareコンポーネントに対する同時実行性の制御方法について説明します。 2.9項「同時実行性の制御」を参照してください。 |
|
ロギング・レベル |
ロギング・レベルは、ログに記録される情報の量を制御するためにシステム管理者が設定するしきい値です。Fusionアプリケーションがログに記録する情報の量はパフォーマンスに影響を与えるため、ロギング・レベルを正しく設定することが重要です。 2.10項「ロギング・レベルの設定」を参照してください。 |
Oracle Fusion Middlewareアプリケーションのパフォーマンス管理における重要な要素は、システムのユーザー要件とアプリケーション要件を満たす十分なCPU、メモリーおよびネットワーク・リソースがあることを確認することです。
どれほど適切にアプリケーションをチューニングしても、適切なハードウェア・リソースがなければ、アプリケーションのパフォーマンスは最適なレベルに達しません。Oracle Fusion Middlewareのアプリケーションおよびデータベース層には、最小限のハードウェア要件があります。Oracle Fusion Middlewareがサポートする構成の詳細は、ご使用のプラットフォームに対応する『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のシステム要件と前提条件に関する項を参照してください。
ハードウェア・リソースが十分であるとは、飽和状態にならずに、アプリケーションで許容されるレベルと同等またはそれ以上のレスポンス時間およびスループットを達成できることです。十分なハードウェア・リソースがあることを確認するには、リソース使用率を長期間にわたって監視し、使用率が一時的にピークに達することがあるのか（あるとすればそれはいつか）、それともリソースが常に飽和状態にあるのかを調べる必要があります。監視の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。
|
ヒント: CPU使用率が100%に達しないようにする必要があります。目標とするCPU使用率は、アプリケーションのニーズ（ピーク時のCPUサイクルなど）に基づいて決定してください。通常負荷時のCPU使用率が100%になるように最適化した場合、ピーク時の負荷を処理するキャパシティは残っていません。待機時間の影響を受けやすく、高速のレスポンス時間を維持することが重要な意味を持つアプリケーションでは、CPU使用率が高い（100%に近づく）と、レスポンス時間が長くなる一方で、スループットは一定に保たれるか、低下します。このようなアプリケーションの場合、推奨されるCPU使用率は70〜80%です。待機時間の影響を受けないアプリケーションの場合は、90%程度を目標とすることをお薦めします。 |
飽和状態になっている（使用率が常に100%か、それに近い）ハードウェア・リソースが1つでもある場合は、次の状況のうち1つ以上が発生している可能性があります。
アプリケーションを実行するのに十分なハードウェア・リソースがない。
システムが正しく構成されていない。
アプリケーションまたはデータベースのチューニングが必要である。
リソースが常に飽和状態にある場合の解決策は、負荷を減らすか、リソースを増やすことです。レスポンス時間の増大が許されないピーク・トラフィック時については、リソースを増やすことを検討するか、トラフィックをスケジュールしなおして（オフピーク時にバッチ処理やバックグラウンド処理をスケジュールするなど）ピーク時の負荷を減らせるかどうか確認してください。
Oracle Fusion Middlewareには、リソースの同時使用を制御する各種メカニズムが用意されています。これにより、トラフィックの急増による影響を抑えることができます。ただし、常に飽和状態にあるシステムでは、こうしたメカニズムも一時的な解決策にすぎません。詳細は、2.9項「同時実行性の制御」を参照してください。
各オペレーティング・システムには、監視やチューニングを目的とする便利なネイティブ・ツールおよびユーティリティが用意されています。オペレーティング・システムのネイティブ・コマンドを使用すれば、CPU使用率、ページング・アクティビティ、スワッピング、その他のシステム・アクティビティ情報を監視できます。
オペレーティング・システム・コマンドの詳細と、ネットワークまたはオペレーティング・システムのパフォーマンス・チューニングに関するガイドラインは、オペレーティング・システム・ベンダー提供のドキュメントを参照してください。
JVMをどのようにチューニングするかによって、Oracle Fusion Middlewareおよびアプリケーションのパフォーマンスが大きく変わります。
|
注意: JVMのパフォーマンスを最大化するために、アプリケーションが認定されている製品版のJVMのみを使用してください。また、最新のオペレーティング・システム・パッチを適用してください。Supported Configurationsページ（ |
この項では、JVMの次のパフォーマンス・チューニング分野について説明します。
|
関連項目: JVMには、ヒープ管理とガベージ・コレクションの動作をさらに細かくチューニングできる様々なパラメータが用意されています。詳細は、付録Bの「Oracle JRockit Java仮想マシン（JVM）」および「Sun Java HotSpot仮想マシン」を参照してください。 |
ガベージ・コレクションは、Javaヒープ内の使用されていないJavaオブジェクトを解放するJVMプロセスです。JVMガベージ・コレクションは、リソースを大量に消費する処理であり、アプリケーションのパフォーマンスに影響を与えます。非効率的なガベージ・コレクションは、アプリケーションのパフォーマンスを大幅に低下させる可能性があります。したがって、アプリケーションでオブジェクトがどのように生成され、破棄されるかを理解しておくことが重要です。
この項では、ガベージ・コレクションに関連する次のチューニング・オプションについて説明します。
ガベージ・コレクションの許容される頻度はアプリケーションによって異なるため、ガベージ・コレクションの実際の所要時間および頻度を分析して調整する必要があります。大きなヒープ・サイズを設定した場合、フル・ガベージ・コレクションは低速化しますが、発生頻度が低くなります。ヒープ・サイズをメモリーのニーズに合せて設定した場合、フル・ガベージ・コレクションは高速化しますが、発生頻度が高くなります。
JVMガベージ・コレクションのオプションをチューニングする場合は、ガベージ・コレクション・データを分析し、ガベージ・コレクションの頻度およびタイプ、メモリー・プールのサイズ、ならびにガベージ・コレクションの所要時間を確認してください。
JVMガベージ・コレクションを構成する前に、次の点を分析します。
ガベージ・コレクションの発生頻度。ガベージ・コレクション前後のタイム・スタンプを比較します。
フル・ガベージ・コレクションの所要時間。
各フル・ガベージ・コレクション後のヒープ・サイズ。たとえば、ヒープの85%が常に空いている場合は、ヒープ・サイズを小さくしてもかまいません。
Young世代のヒープ・サイズ（Sun）またはナーサリのサイズ（JRockit）をチューニングする必要があるか。
verboseガベージ・コレクション・ロギングを使用すると、ガベージ・コレクションおよびメモリー・プールのサイズを手動でログに記録できます。
Sun JVMコマンドライン・オプション:
-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps
主要なコレクションを特定するには、Full GC行を探します。
その他のSunツール:
JStat
JConsole
Visualgc
Sunのオプションの詳細は、http://java.sun.com/javase/technologies/hotspot/gc/index.jspを参照してください。
JRockit JVMコマンドライン・オプション:
-XXverbose:gc
注意: この他にも、JRockit VMのパフォーマンスを改善するコマンドライン・オプションが用意されています。詳細は、JRockit JDKコマンドライン・オプションの名前順リスト（http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html）を参照してください。
その他のJRockitツール:
JRockit Runtime Analyzer（jra recording）
JRockit Management Console（jrmc）
JRockit Memory Leak Detector
ヒープ・サイズをチューニングする目的は、ガベージ・コレクションの所要時間を最小限に抑えながら、Fusion Middlewareスタックが一度に処理できるクライアントの数を最大化することです。
Javaヒープというのは、Javaプログラムのオブジェクトが存在する場所です。ライブ・オブジェクト、デッド・オブジェクトおよび空きメモリーのリポジトリであるとも言えます。実行中のプログラムで、どのポインタからもオブジェクトにアクセスできなくなると、そのオブジェクトはガベージとみなされ、コレクションの対象となります。ベスト・プラクティスとしては、ガベージ・コレクションの所要時間が実行時間の5%以内になるようにチューニングします。
JVMヒープ・サイズによって、ガベージ・コレクションの頻度と所要時間が決まります。ガベージ・コレクションの許容される頻度はアプリケーションによって異なるため、ガベージ・コレクションの実際の所要時間および頻度を分析して調整する必要があります。大きなヒープ・サイズを設定した場合、フル・ガベージ・コレクションは低速化しますが、発生頻度が低くなります。ヒープ・サイズをメモリーのニーズに合せて設定した場合、フル・ガベージ・コレクションは高速化しますが、発生頻度が高くなります。
本番環境では、最小ヒープ・サイズと最大ヒープ・サイズを同じ値に設定し、ヒープを絶えず拡大縮小するために仮想マシンのリソースが無駄に費やされるのを防ぎます。システムで稼働しているすべてのJVMの最大ヒープ・サイズの合計が、使用可能な物理RAMのサイズを超えないようにしてください。この値を超えると、オペレーティング・システムがページングを開始するため、パフォーマンスが大幅に低下します。仮想マシンは常にヒープ・サイズより多くのメモリーを使用します。ヒープ・サイズの設定に加えて、仮想マシンの内部機能に必要なメモリー、仮想マシン外部のネイティブ・ライブラリに必要なメモリー、および永続世代メモリー（クラスおよびメソッドの格納に必要なメモリー）が割り当てられます。
たとえば、次のJVMオプションを使用してヒープをチューニングできます。
ヒープ・メモリーが不足している（メモリー・リークが原因ではない）場合は、-Xmxを大きくします。
ネイティブ・メモリーが不足している場合は、-Xmxを小さくする必要があります。
Oracle JRockitでは、-Xns:<nursery size>を変更してナーサリのサイズをチューニングします。
Sun JVMでは、-Xmnを変更してYoung世代のヒープのサイズをチューニングします。
java.lang.OutOfMemoryError: PermGen spaceエラーが発生した場合は、永続世代の領域を増やすことも必要です。
|
関連項目: Young世代のチューニングの詳細は、『Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning』のYoung世代に関する項（http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#generation_sizing.young_gen）を参照してください。
Oracle JRockitでのヒープ構成の詳細は、診断ガイドのヒープおよびナーサリのサイズ設定に関する項（ SunのJava仮想マシンについては、『Monitoring and Managing Java SE 6 Platform Applications』のメモリー不足に関する項（ 『Frequently Asked Questions』のメモリー不足に関する項（ |
システム・メモリーの管理に使用するガベージ・コレクション方式は、使用しているJVMに応じて、複数の中から選択できます。アプリケーションのタイプによって、最適なガベージ・コレクション方式は異なります。アプリケーションのワークロードやJVMが利用する各種ガベージ・コレクション・アルゴリズムについて理解すれば、ガベージ・コレクションの構成を最適化できるようになります。
各JVMのガベージ・コレクション・オプションについては、次のリンクを参照してください。
Sun社のHotSpot VMで利用可能なガベージ・コレクション方式の概要は、『Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning』（http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html）を参照してください。
利用可能なコレクション方式についての総合的な説明は、『Memory Management in the Java HotSpot™ Virtual Machine』（http://java.sun.com/j2se/reference/whitepapers/memorymanagement_whitepaper.pdf）を参照してください。
JRockit JDKで利用可能なガベージ・コレクション方式については、JRockitのメモリー管理システムの使用方法に関する項（http://download.oracle.com/docs/cd/E13150_01/jrockit_jvm/jrockit/webdocs/index.html）を参照してください。
次のパラメータは、明示的ガベージ・コレクションが発生しているかどうかの診断に使用します。必要な場合は、これらを使用して、コードが修正されるまで明示的ガベージ・コレクションを無効にすることもできます。
Sunの仮想マシンの場合は、-XX:+DisableExplicitGCを使用します。
明示的ガベージ・コレクションの使用の詳細は、『Java SE 6 HotSpot Virtual Machine Garbage Collection Tuning』（http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html）を参照してください。
Oracle JRockit仮想マシンの場合は、-XXnoSystemGCを使用します。
Oracle JRockitのチューニングの詳細は、http://download.oracle.com/docs/cd/E13188_01/jrockit/geninfo/diagnos/bestpractices.htmlを参照してください。
これらのパラメータを指定すると、明示的ガベージ・コレクションが無効になります。アプリケーションでsystem.gc()コールを使用することは避ける必要があります。アプリケーションがガベージ・コレクションを明示的にトリガーしていると思われる場合は、このパラメータを設定し、ガベージ・コレクションの動作の違いを観察してください。パフォーマンスが明示的ガベージ・コレクションの影響を受けているとわかった場合は、コードをチェックし、明示的ガベージ・コレクションが使用されている場所とその理由、およびコールを無効にした場合の影響を調べます。アプリケーション開発者は、ファイナライザをトリガーする目的でsystem.gc()コールを使用することがあります。これは望ましい使用方法ではなく、予測できない動作を生む原因となります。
WebLogic Serverでは、サーバーで観察された低メモリー状態を自動的にログに記録できます。低メモリーを検出するために、使用可能な空きメモリーが一定時間内にあらかじめ設定した回数だけサンプリングされます。各サンプリング期間の最後に、空きメモリーの平均が記録され、次のサンプリング期間に得られた平均と比較されます。サンプリング期間の後、ユーザーがあらかじめ設定した量だけ平均が低下した場合は、低メモリーを示す警告メッセージがログ・ファイルに記録され、サーバーの状態が「警告」に設定されます。
|
関連項目: WebLogic Serverを使用した低メモリー状態の検出の詳細は、次のドキュメントを参照してください。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「低メモリー状態のログへの記録」 『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』の低メモリー状態の自動的なロギングに関する項 |
JVMのパフォーマンスを監視することは、最適なパフォーマンスを得るうえで不可欠です。ご使用のプラットフォームに応じて、次のツールを使用してJVMの監視およびプロファイリングを行います。
Oracle JRockit® Mission Control
Oracle JRockit Mission Controlは、Javaアプリケーションにおけるメモリー・リークの監視、管理、プロファイリングおよび解消を目的とするツール・スイートです。このタイプのツールによくあるように、パフォーマンスに影響を与えることはありません。
Oracle JRockit Mission Controlの詳細は、http://download.oracle.com/docs/cd/E13188_01/jrockit/tools/index.htmlを参照してください。
Sun JVM
Java™プラットフォームには、次の監視機能が組み込まれています。
Java仮想マシン監視および管理API
JConsole
Hprofツール
ロギング、監視および管理用インタフェース
Java Management Extensions（JMX）
Javaプラットフォーム・モニタリング・ツールの詳細は、http://java.sun.com/developer/technicalArticles/J2SE/monitoring/を参照してください。
Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のWebLogic Serverのチューニングにおける重要推奨事項の項を参照してください。
Oracleデータベースを使用するアプリケーションのパフォーマンスを最適化するには、アクセスの対象となるデータベース表を、パフォーマンスを念頭に置いて設計する必要があります。データベースの監視およびチューニングを行えば、アプリケーションから最適なパフォーマンスを確実に得ることができます。
この項の内容は次のとおりです。
|
注意: 必ず、ご使用のデータベースのベンダー・ドキュメントでチューニングに関するガイドラインを確認してください。Oracleデータベースのチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
次の表は、一般的なinit.oraパラメータとその説明をまとめたものです。データベース・パラメータを設定する際には、表に記載されたガイドラインを考慮してください。ただし、最終的にはDBAがデータベースの状態を監視し、必要に応じてパラメータをチューニングする必要があります。詳細は、次の表を参照してください。
次に示す変更を加える前に、パッチ・セット・リリース（PSR）11.1.0.7の適用を検討し、データベースをアップグレードしてください。
次の表では、Oracle 10gデータベースのパフォーマンスに関連するデータベース初期化パラメータについて説明します。
表2-2 Oracle 10gの重要なinit.oraデータベース・チューニング・パラメータ
| データベース・パラメータ | 説明 |
|---|---|
|
DB_BLOCK_SIZE |
DB_BLOCK_SIZEには、Oracleデータベース・ブロックのサイズ（バイト）を指定します。ほとんどのシステムでは、デフォルトのブロック・サイズである8Kが最適です。このパラメータはデータベース作成時に設定します。 |
|
NLS_SORT |
NLS_SORTには、ORDER BY問合せの照合順序を指定します。 値がBINARYの場合、ORDER BY問合せの照合順序は文字の数値に基づいて決定されます（システム・リソースをそれほど必要としないバイナリ・ソート）。 値が言語ソート名の場合、ソートは定義済の言語ソートの順序に基づいて行われます。NLS_LANGUAGEパラメータがサポートするほとんど（すべてではない）の言語は、同じ名前の言語ソートもサポートしています。 |
|
OPEN_CURSORS |
OPEN_CURSORSには、セッションが同時に持つことのできるオープン・カーソル（プライベートSQL領域へのハンドル）の最大数を指定します。このパラメータを使用すると、セッションで過度に多くのカーソルがオープンされるのを防ぐことができます。 OPEN_CURSORSには、アプリケーションでオープン・カーソルが不足しないように、十分に大きな値を設定することが重要です。設定する数値はアプリケーションによって異なります。セッションでオープンされるカーソルの数がOPEN_CURSORSに指定した数より少ないと仮定すると、この値を実際に必要な数より大きく設定しても、パフォーマンスへの影響はありません。 |
|
SESSION_CACHED_CURSORS |
SESSION_CACHED_CURSORSには、キャッシュするセッション・カーソルの数を指定します。同じSQL文の解析コールを繰り返すと、その文のセッション・カーソルがセッション・カーソル・キャッシュに移動されます。その後の解析コールではキャッシュ内のカーソルが使用され、カーソルは再オープンされません。Oracleでは、最低使用頻度アルゴリズムを使用してセッション・カーソル・キャッシュ内のエントリを削除し、必要なときに新しいエントリを格納できるよう余裕を持たせています。 このパラメータは、文が再実行されたときに再解析を行わなくてもよいようにPL/SQLで使用される、PL/SQLカーソル・キャッシュのサイズも制限します。 |
|
SESSION_MAX_OPEN_FILES |
SESSION_MAX_OPEN_FILESには、セッションでオープン可能なBFILEの最大数を指定します。この数値に達した後は、DBMS_LOB.FILEOPEN()またはOCILobFileOpen()を使用して、セッションでそれ以上ファイルをオープンしようとすると失敗します。このパラメータの最大値は、基礎となるオペレーティング・システムで定義されている同等のパラメータに依存します。 |
|
JOB_QUEUE_PROCESSES |
JOB_QUEUE_PROCESSESには、ジョブ実行用に作成可能なプロセスの最大数を指定します。これは、1インスタンス当たりのジョブ・キュー・プロセスの数を示しています。 |
|
LOG_BUFFER |
LOG_BUFFERには、REDOエントリをREDOログ・ファイルにバッファする際に使用されるメモリーの量（バイト）を指定します。REODログ・エントリには、データベース・ブロック・バッファに加えられた変更のレコードが含まれています。REDOログ・エントリは、LGWRプロセスによってログ・バッファからREDOログ・ファイルに書き込まれます。 |
|
UNDO_MANAGEMENT |
UNDO_MANAGEMENTには、システムで使用されるUNDO領域管理モードを指定します。AUTOに設定すると、インスタンスは自動UNDO管理モードで起動されます。手動UNDO管理モードの場合、UNDO領域はロールバック・セグメントとして外部的に割り当てられます。 |
|
PL_SQL_CODE_TYPE |
PLSQL_CODE_TYPEには、PL/SQLライブラリ単位のコンパイル・モードを指定します。 INTERPRETED: PL/SQLライブラリ単位は、PL/SQLバイトコード形式にコンパイルされます。この形式のモジュールは、PL/SQLインタプリタ・エンジンによって実行されます。 NATIVE: PL/SQLライブラリ単位は、ネイティブ（マシン）・コードにコンパイルされます。この形式のモジュールはネイティブに実行されるため、インタプリタの影響を受けません。 |
|
PROCESSES |
Oracleに同時に接続可能なオペレーティング・システム・プロセスの最大数を設定します。このパラメータの値には、Oracleバックグラウンド・プロセスの数を含める必要があります。SESSIONSパラメータはこの値から導出されます。 |
|
PGA_AGGREGATE_TARGET |
インスタンスに属するすべてのサーバー・プロセスで使用可能なターゲットPGAメモリーの総計を指定します。 |
|
SGA_MAX_SIZE |
このパラメータは、実行中インスタンスのSGAの最大サイズです。このパラメータには、SGA専用とするメモリーの量を設定します。SGAには次のメモリー・プールがあります。
必ずSGAのバッファ・キャッシュ・ヒット率およびサイズを定期的に監視し、バッファ・キャッシュのフレーム数がワークロードに対して適正であることを確認してください。バッファ・キャッシュ・ヒット率は、ビュー |
|
SGA_TARGET |
このパラメータをゼロ以外の値に設定すると、自動共有メモリー管理が有効になります。構成の簡素化およびパフォーマンスの改善を図るには、自動メモリー管理の使用を検討してください。 |
|
TRACE_ENABLED |
TRACE_ENABLEDは、Oracleの実行履歴（コード・パス）のトレースを制御します。Oracleサポート・サービスでは、この情報をデバッグに利用しています。 処理によって生じるパフォーマンス上の影響は大きくありませんが、TRACE_ENABLEDをFALSEに設定するとパフォーマンスを改善できることがあります。 |
次の表では、Oracle 11gデータベースのパフォーマンスに関連する重要なデータベース初期化パラメータについて説明します。
表2-3 Oracle 11gの重要なinit.oraデータベース・チューニング・パラメータ
| データベース・パラメータ | 説明 |
|---|---|
|
AUDIT_TRAIL |
AUDIT_TRAILは、データベース監査を有効または無効にします。 |
|
MEMORY_MAX_TARGET |
MEMORY_MAX_TARGETには、DBAがMEMORY_TARGET初期化パラメータに設定できる最大値を指定します。 |
|
MEMORY_TARGET |
MEMORY_TARGETには、Oracleシステム全体で使用可能なメモリーを指定します。データベースでは、SGAおよびPGAを必要に応じて縮小または拡大して、メモリーをMEMORY_TARGETの値にチューニングします。 |
|
PGA_AGGREGATE_TARGET |
インスタンスに属するすべてのサーバー・プロセスで使用可能なターゲットPGAメモリーの総計を指定します。Oracle 11gでは、SGAとPGAを別々に設定するかわりに、MEMORY_TARGETを設定します。 |
|
SGA_MAX_SIZE |
SGAとPGAを別々に設定するかわりに、MEMORY_TARGETを設定することを検討してください。 |
|
SGA_TARGET |
SGAとPGAを別々に設定するかわりに、MEMORY_TARGETを設定することを検討してください。 |
データベースI/Oのロード・バランシングを管理することは、簡単な作業ではありません。しかし、REDOログ・オプションをチューニングすれば、Oracle Fusion Middleware環境で稼働しているアプリケーションのパフォーマンスを改善できます。また、REDOログを別のディスクに移動することで、I/Oスループットを大幅に改善できる場合もあります。
REDOログ・ファイルのサイズはパフォーマンスにも影響を与えます。これは、データベースのライター・プロセスおよびアーカイバ・プロセスの動作がREDOログのサイズによって変わるためです。一般に、REDOログ・ファイルが大きければ、チェックポイント・アクティビティが減少し、パフォーマンスは向上します。REDOログ・ファイルのサイズについて、具体的な推奨値を示すことはできませんが、100MBから数GBの範囲であれば妥当であると考えられます。オンラインREDOログ・ファイルのサイズは、システムで生成されるREDOの量に従って設定してください。大まかなガイドラインとしては、最大20分ごとにログを切り替えます。初期化パラメータLOG_CHECKPOINTS_TO_ALERT = TRUEを設定して、チェックポイント時間がアラート・ファイルに書き込まれるようにします。
必要なREDOログ・ファイル一式を作成できるのは、データベース作成時です。作成後にREDOログ・ファイルのサイズを変更することはできません。ただし、大きなサイズの新しいファイルを後から追加し、元の（小さい）ファイルを削除することは可能です。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
永続表領域については、自動セグメント領域管理の使用を検討してください。ビットマップ表領域と呼ばれることも多い永続表領域は、ビットマップ・セグメント領域管理によってローカルに管理される表領域です。
下位互換性を確保するために、ローカル表領域のデフォルトのセグメント領域管理モードはMANUALに設定されています。
詳細は、『Oracle Database概要』の空き領域管理に関する項、および『Oracle Database管理者ガイド』のローカル管理表領域のセグメント領域管理の指定に関する項を参照してください。
データベース接続の作成は、環境を問わず、比較的リソース消費量の多いプロセスです。通常、起動時の接続プールには少数の接続が含まれています。クライアントからの接続の要求が増えるにつれて、プール内の接続が不足し、要求を満たせなくなることがあります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。
接続作成の遅れを回避する1つの方法は、クライアントの要求に応じて接続を初期化するのではなく、サーバー起動時にすべての接続を初期化することです。この方法は、負荷が一定で、予測可能な場合に適しています。データ・ソース構成の「接続プール」タブで、初期接続数を最大接続数と同一に設定します。本番前のパフォーマンス・テストの一環として、「最大容量」の最適な値を決定します。
負荷が一定せず、ピーク負荷時の接続数が通常負荷時の接続数よりかなり多い場合は、初期接続数を通常負荷時と同一に設定することを検討してください。さらに、対応可能なピーク負荷に基づいて最大接続数を設定することを検討してください。このように構成すれば、WebLogic Serverは一定期間にわたって使用されていない接続を解放できます。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のデータ・ソース接続プール・オプションのチューニングに関する項を参照してください。
アプリケーションまたはEJBでプリコンパイル文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信の処理、およびデータベース・サーバー上での処理に伴って、パフォーマンスに影響が出ることがあります。処理への影響を最小限に抑えるには、アプリケーションで使用されるプリコンパイル文およびコール可能文をデータ・ソースがキャッシュできるようにします。アプリケーションまたはEJBがキャッシュに格納された文をコールした場合、サーバーはキャッシュに格納された文を再利用します。プリコンパイル文およびコール可能文を再利用することで、データベース・サーバーのCPU使用率が低下します。その結果、現在の文のパフォーマンスが向上し、CPUサイクルを他のタスクに割り当てられるようになります。
データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されますが、文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。
文キャッシュ・タイプ: 文キャッシュにどの文を格納するかを決定するアルゴリズム。
文キャッシュ・サイズ: 各接続についてキャッシュに格納する文の数。デフォルト値は10です。データベースの文解析メトリックを分析したうえで、文キャッシュはアプリケーションで使用する文の数に十分対応できるサイズに設定してください。
管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソースの文キャッシュの構成」を参照してください。
文キャッシュの使用の詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』の文キャッシュによるパフォーマンスの向上に関する項を参照してください。
システムの複数のレイヤーで個別の使用ニーズに合せて同時実行性を制限すると、パフォーマンスを大幅に改善できます。この項では、Oracle Fusion Middlewareの中で同時実行性の制御が可能ないくつかの分野について説明します。
システムのキャパシティに達した後も、Webサーバーやアプリケーション・サーバーがリクエストを受け付け続けると、アプリケーションのパフォーマンスおよび安定性が低下します。Oracle Fusion Middlewareには、リクエストを抑制して中間層またはデータベース層のシステムが過負荷の状態になることを避け、最適なパフォーマンスが得られるようチューニングすることのできる分野があります。
Oracle HTTP Serverでは、httpd.confのディレクティブが使用されます。この構成ファイルには、同時に処理可能なHTTPリクエストの最大数、ロギング詳細、ならびに特定の制限およびタイムアウトが指定されています。
httpd.confファイルの変更の詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverの構成に関する項を参照してください。
MaxClientsディレクティブおよびThreadsPerChildディレクティブを使用すると、予想されるクライアント負荷およびシステム・リソースに基づいて、Oracle HTTP ServerからWebLogicインスタンスへの受信リクエストを制限できます。次の各項では、接続制限に関連するOracle HTTP Serverチューニング・パラメータについて説明します。これらは通常、予想されるクライアント負荷に基づいてチューニングする必要があります。詳細とチューニング可能なパラメータの詳しいリストは、第5章「Oracle HTTP Serverのパフォーマンス・チューニング」を参照してください。
|
注意: MaxClientsパラメータはUNIXプラットフォームにのみ適用されます。Microsoft Windows（mpm_winnt）では、ThreadsPerChildパラメータとThreadLimitパラメータで同じ機能が実現されています。 |
MaxClientsプロパティに、稼働しているサーバー・スレッドの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、（ListenBackLogディレクティブで）指定した制限に達するまでTCP/IPシステムのキューに入れられます。
MaxClientsディレクティブはhttpd.confファイルで構成でき、最大値は8K（デフォルト値は150)です。システム・リソースが飽和状態でなく、HTTPの同時接続ユーザー数が150を超えている場合は、MaxClientsを大きくしてサーバーの同時実行性を高めると、パフォーマンスが向上します。システムの利用状況がフル（目安は85%）になるまで、MaxClientsを大きくします。
システム・リソースが飽和状態のときにMaxClientsを大きくしても、パフォーマンスは向上しません。この場合は、サーバーへの同時リクエスト数に対するスロットルとして、MaxClientsの値を小さくします。
サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドルな接続の両方を処理するために十分な数の同時httpdサーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxClientsを指定する際に、アイドル状態の永続的なhttpd接続もhttpdプロセスを消費することを考慮に入れる必要があります。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。使用可能なhttpdサーバー・スレッドがない場合、接続リクエストはスレッドが使用可能になるまでTCP/IPシステムのキューに入れられます。最終的には、クライアントが接続を終了します。
Oracle HTTP Serverへの着信接続を処理するサーバー・プロセスの数、および1プロセス当たりのスレッドの数（ThreadsPerChild）を定義できます。ThreadsPerChildプロパティには、サーバー（子）・プロセスの下に作成可能なスレッドの数の上限を指定します。
|
注意: ThreadsPerChild、StartServers、ServerLimitの各プロパティは、MaxClients設定と相互に関係しています。MaxClientsで指定した数の接続を得るには、これらのプロパティをすべて正しく設定する必要があります。すべてのHTTP構成プロパティの説明は、表5-1「Oracle HTTP Server構成プロパティ」を参照してください。 |
永続的（KeepAlive）なHTTP接続は、接続リクエストの処理中でなくても、接続期間中はhttpd子プロセス（スレッド）を消費します。
十分なキャパシティがある場合は、KeepAliveを有効にしてください。永続的な接続を使用することで、パフォーマンスが向上し、HTTP接続の再確立によるCPUリソースの浪費が回避されます。通常、KeepAliveパラメータの変更は不要です。
|
注意: 永続的な接続に対するデフォルトの最大リクエスト数は100です。これはhttpd.confのMaxKeepAliveRequestsディレクティブで指定されています。デフォルトでは、サーバーはクライアントからのリクエストを15秒間待ってから接続をクローズします。これはhttpd.confのKeepAliveTimeoutディレクティブで指定されています。 |
Oracle HTTP Server（OHS）は、mod_wl_ohsモジュールを使用して、基礎となるWeblogic ServerまたはWeblogic Serverクラスタへリクエストを転送します。mod_wl_ohsの構成の詳細は、configディレクトリのmod_wl_ohs.confファイルで確認できます。
mod_wl_ohsのチューニング・パラメータの詳細は、『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』のOracle HTTP Serverモジュールの理解に関する項を参照してください。
データベースを使用するアプリケーションの場合、データ・ソースに関連付けられている接続プールの接続数を制限すると、パフォーマンスが向上します。MaxCapacity属性を使用してOracle Application Serverからのデータベース・リクエストを制限することで、受信リクエストが原因でデータベースが飽和状態になったり、データベース・アクセスが原因でOracle Application Server層のリソースが過負荷状態になったりすることを回避できます。
接続プールのMaxCapacity属性は、接続プールに作成できる接続の最大数を示します。デフォルトでは、MaxCapacityの値は15に設定されています。最適なパフォーマンスを得るには、データベースのパフォーマンス特性に適した数値をMaxCapacityに指定してください。
オープンしているデータベース接続の総数を、データベースで処理可能な数に制限することは、チューニングの際の重要な考慮事項です。データベースが、すべてのデータ・ソースのMaxCapacityオプションで指定されている値の合計と同じ数以上の接続をオープンできるよう構成されていることを確認してください（このオプションはデータベースにアクセスするすべてのアプリケーションで指定されています）。
|
関連項目: Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「JDBCデータ・ソース: 構成: 接続プール」『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のデータ・ソース接続プール・オプションのチューニングに関する項 |
デフォルトでは、WebLogic Serverが使用するスレッド・プールは1つであり、その中であらゆるタイプの作業が実行されます。WebLogic Serverは、ワーク・マネージャを使用し、ユーザー定義ルールおよびランタイム・メトリック（リクエストの実行に要する実際の時間や、リクエストがプールに入る頻度とプールを出る頻度など）に基づいて処理の優先順位を決定します。共通のスレッド・プールを管理するデフォルトのワーク・マネージャが存在します。
共通のスレッド・プールのサイズは、スループットが最大になるように自動的に変化します。WebLogic Serverでは、履歴に基づいてスループットを長期的に監視し、スレッド数の調整が必要かどうかを判断しています。たとえば、過去のスループット統計から、スレッド数を増やしたらスループットが向上したと判明した場合は、スレッド数を増やします。同様に、スレッド数を減らしてもスループットが低下しなかったと統計から判明した場合は、スレッド数を減らします。
WebLogic Serverのスレッド・プールのサイズはデフォルトで自動的に設定されるため、チューニングの必要はないことがほとんどです。ただし、特殊な要件がある場合は、管理者がカスタム・ワーク・マネージャを構成して、同様のパフォーマンス要件、可用性要件または信頼性要件を持つリクエスト・セットごとに、スレッド・プールをきめ細かく管理できます。カスタム・ワーク・マネージャでは、保留中の作業の割当て方法に関する優先順位およびガイドラインを定義できます。たとえば、最小スレッド数または最大スレッド数に対する制約や、WebLogic Serverがリクエストを拒否し始めるまでにキューに入れる、または実行することのできるリクエストの総数に対する制約を指定します。
ワーク・マネージャを使用してスレッド管理をカスタマイズする必要があるかどうかは、次のガイドラインを基に判断してください。
デフォルト値では不十分である。
通常、これが該当するのは、特定のアプリケーションに他のアプリケーションより高い優先順位を付ける必要がある場合です。
レスポンス時間の目標を設定する必要がある。
最小スレッド数制約を指定して、サーバーのデッドロックを回避する必要がある。
アプリケーションでMDBを使用している。
MDBに割り当てるサーバー・スレッド・リソースを明確に定義して、それをMDBに確実に使用させる場合や、MDBの同時実行性をチューニングする場合は、最大スレッド数制約が指定されたカスタム・ワーク・マネージャを参照するように、ほとんどのMDBを変更する必要があります。一般に、カスタム・ワーク・マネージャが便利なのは、複数のMDBデプロイメントが存在する場合や、特定のMDBが多くのスレッドを必要とする場合です。
|
関連項目: カスタム・ワーク・マネージャを使用してスレッド管理をカスタマイズする方法、およびカスタム・ワーク・マネージャを使用する必要があるかどうかの判断の詳細は、次のドキュメントを参照してください。
Oracle WebLogic管理コンソールを使用すると、スレッド・プールのステータスの概要（アクティブ・スレッド数、合計スレッド数、キューの長さなど）を確認できます。コンソールでは、監視中ページの「ワークロード」タブから、各アプリケーションに設定したワーク・マネージャ・メトリックも確認できます。表示されるメトリックは、保留中リクエストの数や完了したリクエストの数などです。 詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「サーバー: 監視: スレッド」および「デプロイメント: 監視: ワークロード」を参照してください。 ワーク・マネージャおよびスレッド・プールのメトリックは、Oracle Fusion Middleware Controlからも確認できます。詳細は、4.2.1項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの確認」を参照してください。 |
Oracle WebCenterには、同時実行性を管理するための独自のコントロールがあります。Oracle Fusion Middleware Oracle WebCenterの管理者ガイドの同時実行性管理の構成に関する項を参照してください。
Oracle BPEL Process Managerには、独自のスレッド・コントロールと特殊なチューニング機能が用意されています。12.2.1項「BPELスレッド・モデル」を参照してください。
Fusionアプリケーションがログに記録する情報の量は、環境の構成およびアプリケーション・コードのインスツルメント状況によって異なります。パフォーマンスを最大化するには、デフォルトのINFOレベルより高いロギング・レベルを設定しないでください。ロギング設定がデフォルト・レベルと異なる場合は、最適なパフォーマンスが得られるよう、ロギング・レベルをデフォルトに戻します。
アプリケーションおよびサーバーのロギング・レベルを正しく設定したら、デバッグ・プロパティやアプリケーション・レベルのその他のデバッグ・フラグが適切なレベルに設定されているか、または無効になっていることを確認します。パフォーマンスへの影響を回避するには、ロギング・レベルを、より多くの診断メッセージが生成されるレベル（FINEレベルまたはTRACEレベル）に設定しないでください。
Oracle Fusion Middlewareアプリケーションに適したロギング・レベルの設定の詳細は、Oracle Fusion Applicationsの開発者ガイドのロギングおよび診断用開発環境の構成に関する項を参照してください。
