主なパフォーマンス分野

2 主なパフォーマンス分野

パフォーマンス分野を特定することで、最適なパフォーマンスを得るためにOracle Fusion Middlewareをチューニングできます。

主なパフォーマンス分野の特定
パフォーマンス・チューニングの最も難しい面の1つは、どこから始めればよいかを知ることです。したがって、Oracle Fusion Middlewareのパフォーマンス分野を特定することが重要です。
十分なハードウェア・リソースの確保
Oracle Fusion Middlewareアプリケーションのパフォーマンスを管理し、システムのユーザー要件とアプリケーション要件を満たす十分なCPU、メモリーおよびネットワーク・リソースがあることを確認します。
オペレーティング・システムのチューニング
各オペレーティング・システムには、モニタリングやチューニングを目的とする便利なネイティブ・ツールおよびユーティリティが用意されています。
Java仮想マシン(JVM)のチューニング
Java仮想マシン(JVM)をどのようにチューニングするかによって、Oracle Fusion Middlewareおよびアプリケーションのパフォーマンスが大きく変わります。
WebLogic Serverのチューニング
アプリケーションのニーズに合せてWebLogic Serverをチューニングします。
データベース・パラメータのチューニング
Oracleデータベースを使用するアプリケーションのパフォーマンスを最適化するには、アクセスの対象となるデータベース表を、パフォーマンスを念頭に置いて設計する必要があります。データベースのモニタリングおよびチューニングを行えば、アプリケーションから最適なパフォーマンスを確実に得ることができます。
データベース接続の再利用
WebLogic ServerドメインにあるJDBCデータ・ソースの接続プール属性を適切に調整して、アプリケーションおよびシステムのパフォーマンスを向上させることが重要です。
データ・ソースの文キャッシュの有効化
文キャッシュを使用すると、何度も使用される実行可能文をキャッシュすることによってパフォーマンスを向上させることができます。
同時実行性の制御
システムの複数のレイヤーで個別の使用ニーズにあわせて同時実行性を制限すると、パフォーマンスを大幅に改善できます。
ロギング・レベルの設定
ログに記録される情報の量は、パフォーマンスに大きく影響することがあります。

親トピック: 概要

主なパフォーマンス分野の特定

パフォーマンス・チューニングの最も難しい面の1つは、どこから始めればよいかを知ることです。したがって、Oracle Fusion Middlewareのパフォーマンス分野を特定することが重要です。

表2-1は、Oracle Fusion Middlewareのパフォーマンスに関する一般的な考慮事項をリストにまとめたものです。このリストは、パフォーマンス・チューニングを始めるうえで有効なツールとなりますが、チューニングが必要な分野をすべて網羅してはいません。アプリケーションにおけるパフォーマンスの問題を個別にモニター、追跡し、どこをチューニングすればパフォーマンスが向上するかを把握する必要があります。「モニタリング」を参照してください。

表2-1 Oracle Fusion Middlewareの主なパフォーマンス分野

パフォーマンス分野	説明と参照先
ハードウェア・リソース	パフォーマンスを最大化するために、リソース要件と同等またはそれ以上のハードウェア・リソースがあることを確認します。ハードウェア・リソースが十分かどうかを判断する方法の詳細は、十分なハードウェア・リソースの確保を参照してください。
オペレーティング・システム	各オペレーティング・システムには、モニタリング目的に役立つ可能性のあるネイティブ・ツールおよびユーティリティがあります。オペレーティング・システムのチューニングを参照してください。
Java仮想マシン(JVM)	ベスト・プラクティスおよび実用的なヒントに従って、JVMをチューニングします。また、ヒープ・サイズやJVMガベージ・コレクションのオプションなど、Java EEアプリケーションのパフォーマンスを向上させます。「Java仮想マシン(JVM)のチューニング」を参照してください。
データベース	データベースにアクセスするアプリケーションの場合は、データベースがアプリケーションの要件に合せて正しく構成されていることを確認します。データベース・パラメータのチューニングを参照してください。
WebLogic Server	Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、「WebLogic Serverのチューニング」を参照してください。
データベース接続	接続を再利用するための接続プーリングは、チューニングの際の重要な考慮事項です。データベース接続の再利用を参照してください。
データ・ソースの文キャッシュ	データベースを使用するアプリケーションの場合は、文キャッシュを正しく構成することで、繰り返し実行される文の解析および作成がパフォーマンスに与える影響を軽減できます。データ・ソースの文キャッシュの有効化を参照してください。
Oracle HTTP Server	Oracle HTTP Serverディレクティブをチューニングし、HTTP接続数を指定して同時実行性のレベルを設定します。「同時実行性の制御」を参照してください。
同時実行性	Oracle Fusion Middlewareコンポーネントとの同時実行性を制御します。「同時実行性の制御」を参照してください。
ロギング・レベル	ロギング・レベルは、ログに記録される情報の量を制御するためにシステム管理者が設定するしきい値です。アプリケーションがログに記録する情報の量はパフォーマンスに影響を与えるため、ロギング・レベルを正しく設定します。ロギング・レベルの設定を参照してください。

親トピック: 主なパフォーマンス分野

十分なハードウェア・リソースの確保

Oracle Fusion Middlewareアプリケーションのパフォーマンスを管理し、システムのユーザー要件とアプリケーション要件を満たす十分なCPU、メモリーおよびネットワーク・リソースがあることを確認します。

どれほど適切にアプリケーションをチューニングしても、適切なハードウェア・リソースを使用しなければ、アプリケーションのパフォーマンスは最適なレベルに達しません。Oracle Fusion Middlewareのアプリケーションおよびデータベース層には、最小限のハードウェア要件があります。Oracle Fusion Middlewareでサポートされる構成の詳細は、『Oracle Fusion Middlewareのインストールのプランニング』の動作保証、システム要件および相互運用性の確認に関する項を参照してください。

ハードウェア・リソースが十分であるとは、飽和状態にならずに、アプリケーションで許容されるレベルと同等またはそれ以上のレスポンス時間およびスループットを達成できることです。十分なハードウェア・リソースがあることを確認するには、リソース使用率を長期間にわたってモニターし、使用率が一時的にピークに達することがあるのか(あるとすればそれはいつか)、それともリソースが常に飽和状態にあるのかを調べる必要があります。モニタリングの詳細は、「モニタリング」を参照してください。

ヒント:

CPU使用率が決して100%に達しないようにする必要があります。目標とするCPU使用率は、アプリケーションのニーズ(ピーク時のCPUサイクルなど)に基づいて決定してください。

通常の負荷時にCPU使用率が100%に最適化されている場合、ピーク時の負荷を処理するキャパシティが残っていないことになります。待機時間の影響を受けやすいアプリケーションでは、高速のレスポンス時間を維持することが重要です。CPU使用率が高い(100%に近づく)と、レスポンス時間が長くなる一方で、スループットは一定に保たれるか、低下します。このようなアプリケーションの場合、推奨されるCPU使用率は70から80%です。待機時間の影響を受けないアプリケーションの場合は、90%程度を目標とすることをお薦めします。

飽和状態になっている(使用率が常に100%か、それに近い)ハードウェア・リソースが1つでもある場合は、次の状況のうち1つ以上が発生している可能性があります。

アプリケーションを実行するのに十分なハードウェア・リソースがない。
システムが正しく構成されていない。
アプリケーションまたはデータベースのチューニングが必要である。

リソースが常に飽和状態にある場合の解決策は、負荷を減らすか、リソースを増やすことです。レスポンス時間の増大が許されないピーク・トラフィック時については、リソースを増やすことを検討するか、トラフィックをスケジュールしなおすことができるかどうかを確認します。ピーク時の負荷を減らすには、オフピーク時にバッチ処理やバックグラウンド処理をスケジュールする必要があります。

Oracle Fusion Middlewareには、リソースの同時使用を制御する各種メカニズムが用意されています。これにより、トラフィックの急増による影響を抑えることができます。ただし、常に飽和状態にあるシステムでは、こうしたメカニズムも一時的な解決策にすぎません。「同時実行性の制御」を参照してください。

親トピック: 主なパフォーマンス分野

オペレーティング・システムのチューニング

各オペレーティング・システムには、モニタリングやチューニングを目的とする便利なネイティブ・ツールおよびユーティリティが用意されています。

オペレーティング・システムのネイティブ・コマンドを使用すれば、CPU使用率、ページング・アクティビティ、スワッピング、その他のシステム・アクティビティ情報をモニターできます。

オペレーティング・システム・コマンドの詳細と、ネットワークまたはオペレーティング・システムのパフォーマンス・チューニングに関するガイドラインは、オペレーティング・システム・ベンダー提供のドキュメントを参照してください。

親トピック: 主なパフォーマンス分野

Java仮想マシン(JVM)のチューニング

Java仮想マシン(JVM)をどのようにチューニングするかによって、Oracle Fusion Middlewareおよびアプリケーションのパフォーマンスが大きく変わります。

JVMのチューニングの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』のJava仮想マシン(JVM)のパフォーマンス・チューニングに関する項を参照してください。

親トピック: 主なパフォーマンス分野

WebLogic Serverのチューニング

アプリケーションのニーズに合せてWebLogic Serverをチューニングします。

Oracle Fusion MiddlewareアプリケーションがWebLogic Serverを使用している場合は、『Oracle WebLogic Serverのパフォーマンスのチューニング』の「WebLogic Serverのチューニング」を参照してください。

親トピック: 主なパフォーマンス分野

データベース・パラメータのチューニング

Oracleデータベースを使用するアプリケーションのパフォーマンスを最適化するには、アクセスの対象となるデータベース表を、パフォーマンスを念頭に置いて設計する必要があります。データベースのモニタリングおよびチューニングを行えば、アプリケーションから最適なパフォーマンスを確実に得ることができます。

ノート:

ここに記載されている一連の情報は、Fusion Middlewareのデータベース・チューニング情報のサブセットです。また、データベース・パフォーマンス・チューニング・ガイドを参照したことも確認してください。

必ず、ご使用のデータベースのベンダー・ドキュメントでチューニングに関するガイドラインを確認してください。

親トピック: 主なパフォーマンス分野

データベース・パラメータのチューニング

次の表は、一般的なinit.oraパラメータとその説明をまとめたものです。データベース・パラメータを設定する際には、これらのガイドライン従います。ただし、最終的にはデータベース管理者がデータベースのヘルスを監視し、必要に応じてパラメータをチューニングする必要があります。

SOA用に使用されるデータベースは、提案値で構成されます。データベースのチューニングでは、データベースにおける負荷と使用可能なリソースに基づいて、サイズ設定パラメータの調整が必要です。

表2-2のsga_target、pga_aggregate_targetおよびprocessesのパラメータは、システム・グローバル領域(SGA)と親グローバル領域(PGA)のアドバイザに基づいてチューニングし、開いているプロセスの数をピーク負荷時に調べる必要があるそのようなパラメータの例です。

表2-2 重要なOracle 12cデータベース・チューニング・パラメータ

パラメータ	説明	チューニングに関する推奨事項
`audit_trail` デフォルト: `DB`	データベースの監査を使用可能または使用禁止にします。	データベース・アクティビティを監査するポリシーがない場合は、`NONE`に設定します。監査を有効にすると、パフォーマンスに影響が出る可能性があります。
`plsql_code_type` デフォルト: `INTERPRETED`	PL/SQLライブラリ・ユニットのコンパイル・モード。可能なモードは次のとおりです。 `INTERPRETED`: PL/SQLライブラリ単位は、PL/SQLバイトコード形式にコンパイルされ、PL/SQLインタプリタ・エンジンによって実行されます。 `NATIVE`: PL/SQLライブラリ単位は、ネイティブ(マシン)・コードにコンパイルされます。この形式のモジュールはネイティブに実行されるため、インタプリタの影響を受けません。	`NATIVE`に設定します。
`nls_sort` デフォルト: `NLS_LANGUAGE`から導出	`ORDER BY`問合せの照合順序。値が名前付き言語ソートの場合、照合順序は定義されている言語ソートの順序に基づきます。`NLS_LANGUAGE`パラメータでサポートされるほとんどの言語は、同名の言語ソートもサポートします。値が`BINARY`に設定されている場合、照合順序は文字の数値に基づきます。これにより、必要とするシステム・リソースは少なくてすみます。	`BINARY`に設定します。
`open_cursors` デフォルト: `50`	セッションで一度に保持できるオープン・カーソルの最大数。オープン・カーソルは、プライベートSQL領域へのハンドルです。 `OPEN_CURSORS`値には、アプリケーションでオープン・カーソルが不足しないように十分な値を設定する必要があります。	`500`に増加します。
`session_cached_cursors` デフォルト: `50`	キャッシュするセッション・カーソルの数。同じSQL文の解析コールを繰り返すと、その文のセッション・カーソルがセッション・カーソル・キャッシュに移動されます。後続の解析コールでは、キャッシュでカーソルが検索されます。ただし、カーソルは再オープンされません。Oracleでは、最低使用頻度アルゴリズムを使用してセッション・カーソル・キャッシュ内のエントリを削除し、必要なときに新規エントリのために領域を空けます。このパラメータは、文が再実行されたときに再解析を行わなくてもよいようにPL/SQLで使用される、PL/SQLカーソル・キャッシュのサイズも制限します。	`500`に増加します。
`_b_tree_bitmap_plans` デフォルト: `TRUE`	Bツリー索引のビットマップ・アクセス・パスの使用を有効化または無効化します。	`FALSE`に設定します。
`processes` デフォルト: `100`	Oracleデータベースに同時に接続可能なオペレーティング・システム・プロセスの最大数。このパラメータの値には、Oracleバックグラウンド・プロセスの数を含める必要があります。 `SESSIONS`パラメータはこの値から導出されます。	大半のシステムでは`1500`に増加することで十分です。ユーザー数が多いデータベースなど、大規模のシステムでは、推奨値は`5000`です。
`Memory_target`	Oracleシステム全体で使用可能なメモリー。データベースは`MEMORY_TARGET`に対するメモリーをチューニングして、必要に応じてSGAおよびPGAを削減または増大します。	`NONE`に設定することを検討してください。`MEMORY_TARGET`設定によってSGAおよびPGAターゲットに十分なメモリーが割り当てられないときは、必要に応じてSGAおよびPGAを個別に設定します。
`sga_target` デフォルト: `0`	ゼロ以外の値に設定すると、自動共有メモリー管理が有効になります。これにより構成を単純にでき、パフォーマンスを向上できます。	小規模のシステムでは、最小値の`2 GB`を使用します。大規模のシステムでは、これを`18 GB`に設定します。
`pga_aggregate_target` デフォルト: `0`	インスタンスに添付されたすべてのサーバー・プロセスに利用できるターゲット集計PGAメモリー。	小規模のシステムでは、最小値の`1 GB`を使用します。大規模のシステムでは、これを`8 GB`に設定します。
`Disk_asynch_io` デフォルト: `TRUE`	データ・ファイル、制御ファイルおよびログ・ファイルのI/Oが非同期であるかどうかを制御します。表スキャン中にI/OリクエストをCPU処理と同時実行可能なパラレル・サーバー・プロセスを決定します。	プラットフォームが非同期I/Oをサポートしていない場合にのみ、`FALSE`に設定します。
`Filesystemio_options` デフォルト: `なし`	ファイル・システムのファイルに対するI/O操作。	`SETALL`に設定します。
`Secure_Files` デフォルト: `PERMITTED`	表からLOBオブジェクトを格納する方法。	`ALWAYS`に設定します。
`parallel_max_servers` デフォルト: `PARALLEL_THREADS_PER_CPUCPU_COUNTconcurrent_parallel_users*5`	インスタンスのパラレル実行プロセスおよびパラレル・リカバリ・プロセスの最大数。需要が増加するにつれて、Oracle Databaseではインスタンスの起動時に作成された数からこの値までプロセス数が増加します。	`12`に設定します。
`job_queue_processes` デフォルト: `1000`	`DBMS_JOBジョブ`およびOracle Scheduler(`DBMS_SCHEDULER`)ジョブの実行用に作成可能な、インスタンスごとのジョブ・スレーブの最大数。	12に設定します。
`shared_servers` デフォルト: `0`(または)`1`	インスタンスの起動時に作成するサーバー・プロセスの数。	`0`に設定します。

次の表では、重要なinit.oraデータベース・チューニング・パラメータについて説明します。

表2-3 Oracle 12cの重要なinit.oraデータベース・チューニング・パラメータ

データベース・パラメータ	説明
`AUDIT_TRAIL`	データベース・アクティビティを監査するポリシーがない場合は、このパラメータを`NONE`に設定することを検討してください。監査を有効にすると、パフォーマンスに影響が出る可能性があります。
`MEMORY_MAX_TARGET`	データベース管理者が`MEMORY_TARGET`初期化パラメータを設定できる最大値。
`MEMORY_TARGET`	`NONE`に設定することを検討してください。`MEMORY_TARGET`設定によって必要に応じてSGAおよびPGAに十分なメモリーが割り当てられないとき、SGAおよびPGAを個別に設定します。
`PGA_AGGREGATE_TARGET`	最初にPGAに値1Gを使用することを検討してください。その後、本番データベースを毎日モニターし、それに応じてSGAおよびPGAを調整します。データベース・サーバーのメモリーに余裕がある場合は、`PGA_AGGREGATE_TARGET`を使用ニーズに基づいて1Gより大きい値に設定することを検討してください。
`SGA_MAX_SIZE`	SGAとPGAを別々に設定するかわりに、`MEMORY_TARGET`を設定することを検討してください。
`SGA_TARGET`	最初に`2G`の値を使用することを検討してください。その後、本番データベースを毎日モニタリングし、それに応じてSGAおよびPGAを調整します。データベース・サーバーのメモリーに余裕がある場合は、`SGA_TARGET`を使用ニーズに基づいて`2G`,より大きい値に設定することを検討してください。

さらに、SHARED_POOL_SIZEとDB_CACHE_SIZEの最小値を設定して、頻繁にサイズ変更することを最小限にします。

親トピック: データベース・パラメータのチューニング

データベース・ファイルのチューニング

データベース・パラメータのチューニングに加えて、データベース管理者は、REDOログ、UNDO表領域およびTEMP表領域を構成して、データベース・ワークロードの需要を満たす必要があります。ここに記載されている推奨事項は、これらの領域における初期ガイドを示すことを意図しています。

データベース・ファイルの場所をI/Oパフォーマンスと増大のために最適化する必要があります。セグメント・アドバイザを利用して、セグメント領域の使用を最適化し、パフォーマンス低下が発生しないようにする必要があります。また、セグメントのこれまでの増加傾向を提示でき、プロアクティブな成長計画に使用できます。『Oracle Database管理者ガイド』のセグメント・アドバイザの使用に関する項を参照してください。

REDOログの構成
UNDO表領域の構成
TEMP表領域の構成
追加の表領域の作成
ワークロードの要件に基づいて、追加の表領域を作成することをお薦めします。

親トピック: データベース・パラメータのチューニング

REDOログの構成

負荷の高いワークロードの状況では、REDOログ・ファイルのサイズがパフォーマンスに影響することがあります。一般に、REDOログ・ファイルが大きければ、パフォーマンスは向上します。ログ・ファイルのサイズが小さいと、チェックポイント・アクティビティとログ・ファイル切替えが増加し、パフォーマンスが低下します。Enterprise Managerの「REDOログ・グループ」ページで、サイズ上のメリットが得られます。

記憶域の構成とパフォーマンスの特徴によっては、REDOログを再分散して、I/Oパフォーマンスを最適化します。I/Oパフォーマンスを向上させるには、REDOログ・ファイルをデータ・ファイルとは別のディスク上に配置する必要があります。

『Oracle Database管理者ガイド』のアーカイブREDOログの管理に関する項を参照してください

親トピック: データベース・ファイルのチューニング

UNDO表領域の構成

UNDO表領域の最小提案サイズは、自動拡張が有効な状態で6 GBです。自動UNDO管理のデフォルト・モードを利用して、パフォーマンスと効率を最大化することをお薦めします。

Oracle Enterprise Managerの自動UNDO管理アドバイザを利用して、UNDO表領域と保存設定の構成詳細を設定する必要があります。また、このアドバイザによりUNDOアドバイザにアクセスして新しいUNDO保存設定の影響が評価され、アドバイスが提示されます。アドバイザの使用方法の詳細は、Oracle Database管理者ガイドのUNDOアドバイザPL/SQLインタフェースに関する項を参照してください。

親トピック: データベース・ファイルのチューニング

TEMP表領域の構成

割当てタイプがUNIFORMエクステントに設定され、デフォルト・サイズが1MBのローカル管理一時表領域を使用することをお薦めします。

SOAのTEMP表領域のチューニングの詳細は、SOAの一時表領域のチューニングを参照してください。

親トピック: データベース・ファイルのチューニング

追加の表領域の作成

ワークロードの要件に基づいて、追加の表領域を作成することをお薦めします。

次のいずれかのオプションを使用すると、表領域のサイズを増やすことができます:

データファイルのサイズ変更: データファイルのサイズを変更できます。たとえば、データベースにさらに領域が必要になった場合、1つ以上のデータファイルのサイズを大きくできます。詳細は、データファイルのサイズ変更に関する項を参照してください。
データファイルの作成および表領域への追加: 様々なSQL文を使用して、データファイルを作成し、それらを表領域に関連付けることができます。詳細は、データファイルの作成および表領域への追加に関する項を参照してください。
データファイルの自動拡張の有効化と無効化: データベースにより多くの領域が必要になるとデータファイルのサイズが自動的に増加するように、データファイルを作成または既存データファイルを変更できます。ファイル・サイズは、指定された単位ずつ、指定の最大サイズまで増加します。詳細は、データファイルの自動拡張の有効化と無効化に関する項を参照してください。

追加の表領域を作成するサンプル・スクリプト:

CREATE TABLESPACE apps_tbs LOGGING 
     DATAFILE '/u01/app/oracle/oradata/mynewdb/apps01.dbf' 
     SIZE 500M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED 
     EXTENT MANAGEMENT LOCAL;
-- create a tablespace for indexes, separate from user tablespace (optional)
CREATE TABLESPACE indx_tbs LOGGING 
     DATAFILE '/u01/app/oracle/oradata/mynewdb/indx01.dbf' 
     SIZE 100M REUSE AUTOEXTEND ON NEXT  1280K MAXSIZE UNLIMITED 
     EXTENT MANAGEMENT LOCAL;

親トピック: データベース・ファイルのチューニング

「自動セグメント領域管理(ASSM)のチューニング」

永続表領域については、自動セグメント領域管理の使用を検討してください。ビットマップ表領域と呼ばれることも多い永続表領域は、ビットマップ・セグメント領域管理によってローカルに管理される表領域です。

後方互換性を確保するために、ローカル表領域のデフォルトのセグメント領域管理モードはMANUALに設定されています。

割当てタイプをSYSTEMに指定することをお薦めします。

『Oracle Database管理者ガイド』の空き領域の管理およびローカル管理表領域のセグメント領域管理の指定に関する項を参照してください。

親トピック: データベース・パラメータのチューニング

データベース接続の再利用

WebLogic ServerドメインにあるJDBCデータ・ソースの接続プール属性を適切に調整して、アプリケーションおよびシステムのパフォーマンスを向上させることが重要です。

データベース接続の作成は、環境内ではリソース消費量の多いプロセスです。通常、起動時の接続プールには少数の接続が含まれています。クライアントからの接続の要求が増えるにつれて、プール内の接続が不足し、要求を満たせなくなります。WebLogic Serverは、最大プール・サイズに達するまで、接続をさらに作成してプールに追加します。

接続作成の遅れを回避する1つの方法は、接続を初期化するのではなく、サーバー起動時にすべての接続を初期化することです。この方法は、負荷が一定で、予測可能な場合に適しています。データ・ソース構成の「接続プール」タブの接続の初期数の値を接続の最大数の値と等しい設定します。本番前のパフォーマンス・テストの一環として、「最大容量」の最適な値を決定します。

負荷が一定せず、ピーク負荷時の接続数が通常負荷時の接続数よりかなり多い場合は、初期接続数を通常負荷時と同一に設定します。さらに、対応可能なピーク負荷に基づいて最大接続数を設定します。このように構成すれば、WebLogic Serverは使用されていない接続を解放できます。

『Oracle WebLogic Server JDBCデータ・ソースの管理』のデータ・ソース接続プールのチューニング・オプションに関する項を参照してください。

親トピック: 主なパフォーマンス分野

データ・ソースの文キャッシュの有効化

文キャッシュを使用すると、何度も使用される実行可能文をキャッシュすることによってパフォーマンスを向上させることができます。

アプリケーションまたはEJBでプリコンパイル文やコール可能文を使用すると、アプリケーション・サーバーとデータベース・サーバーの間の通信の処理処理に伴って、パフォーマンスに影響が出ます。処理への影響を最小限に抑えるには、アプリケーションで使用されるプリコンパイル文およびコール可能文をデータ・ソースがキャッシュできるようにします。アプリケーションまたはEJBがキャッシュに格納された文をコールした場合、サーバーはキャッシュに格納された文を再利用します。プリペアド文またはコール可能文を再利用すると、データベース・サーバー上のCPU使用量が低減され、現在の文のパフォーマンスが向上します。また、CPUサイクルを別のタスクを行うために使用できます。

パフォーマンスが問題になっている場合は、次のデータ・ソース構成を検討してください。

データ・ソースを構成する際には、接続プールに十分な数の使用可能な接続があることを確認します。
文キャッシュを使用すると、カーソル作成の繰返しと文の解析および作成の繰返しがパフォーマンスに与える影響を解消できます。文キャッシュを使用することで、アプリケーション・サーバーとデータベース・サーバーの間の通信がパフォーマンスに与える影響も軽減できます。
不要な接続テストおよびプロファイリングは無効にします。

データ・ソース内の各接続には、その接続で使用されるプリコンパイル文およびコール可能文の専用キャッシュがあります。ただし、文キャッシュ・オプションはデータ・ソースごとに構成します。つまり、データ・ソースに指定した文キャッシュ・オプションはそのデータ・ソース内の各接続の文キャッシュで使用されます。文は接続ごとにキャッシュされます。文キャッシュの構成オプションは次のとおりです。

文キャッシュ・タイプ—文キャッシュにどの文を格納するかを決定するアルゴリズム。
文キャッシュ・サイズ—各接続についてキャッシュに格納する文の数。デフォルト値は10です。データベースの文解析メトリックを分析したうえで、文キャッシュはアプリケーションで使用する文の数に十分対応できるサイズに設定します。

管理コンソールを使用して、データ・ソースの文キャッシュ・オプションを設定できます。

文キャッシュの使用の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』の文キャッシュによるパフォーマンスの向上に関する項を参照してください。

親トピック: 主なパフォーマンス分野

同時実行性の制御

システムの複数のレイヤーで個別の使用ニーズに合せて同時実行性を制限すると、パフォーマンスを大幅に改善できます。

システムのキャパシティに達した後も、Webサーバーやアプリケーション・サーバーがリクエストを受け付け続けると、アプリケーションのパフォーマンスおよび安定性が低下します。Oracle Fusion Middleware内では、リクエストを抑制して中間層またはデータベース層のシステムが過負荷の状態になることを避け、最適なパフォーマンスが得られるようチューニングできます。

親トピック: 主なパフォーマンス分野

サーバー接続制限の設定

Oracle HTTP Serverでは、httpd.confファイル内のディレクティブが使用されます。この構成ファイルには、同時に処理可能なHTTPリクエストの最大数、ロギング詳細、ならびに特定の制限およびタイムアウトが指定されています。

httpd.confファイルの変更方法の詳細は、『Oracle HTTP Serverの管理』のOracle HTTP Serverの構成に関する項を参照してください。

予想されるクライアント負荷およびシステム・リソースに基づいて、Oracle HTTP ServerからWebLogicインスタンスへの受信リクエストを制限するには、MaxRequestWorkersディレクティブおよびThreadsPerChildディレクティブを使用します。接続制限に関連するOracle HTTP Serverチューニング・パラメータには様々なものがあり、予想されるクライアント負荷に基づいてチューニングする必要があります。サーバー接続制限の詳細およびチューニング可能なパラメータの詳しいリストは、「Oracle HTTP Serverのチューニング」を参照してください。

親トピック: 同時実行性の制御

MaxRequestWorkers / ThreadsPerChildの設定

ノート:

MaxRequestWorkersパラメータはUNIXプラットフォームにのみ適用されます。Microsoft Windows (mpm_winnt)のThreadsPerChildおよびThreadLimitパラメータを使用しても、同じことを実行できます。

MaxRequestWorkersパラメータに、稼働しているサーバー・スレッドの総数に対する制限、つまり同時に接続可能なクライアントの数に対する制限を指定します。クライアント接続数がこの制限に達すると、その後のリクエストは、(ListenBackLogディレクティブで)指定した制限に達するまでTCP/IPシステムのキューに入れられます。

MaxRequestWorkersディレクティブはhttpd.confファイルで構成でき、最大値は8K (デフォルト値は150)です。システム・リソースが飽和状態でなく、HTTPの同時接続ユーザー数が150を超えている場合は、MaxRequestWorkersを大きくしてサーバーの同時実行性を高めて、パフォーマンスを向上します。システムの利用状況がフル(目安は85%)になるまで、MaxRequestWorkersを大きくします。

システム・リソースが飽和状態のときにMaxRequestWorkersを大きくしても、パフォーマンスは向上しません。この場合は、サーバーへの同時リクエスト数に対するスロットルとして、MaxRequestWorkersの値を小さくします。

サーバーが永続的な接続を処理する場合は、アクティブな接続とアイドルな接続の両方を処理するために十分な数の同時httpdサーバー・プロセスが必要になります。システムの同時実行性に対するスロットルとしてMaxRequestWorkersを指定するとき、アイドル状態の永続的なhttpd接続もhttpdプロセスを消費することを考慮に入れます。つまり、接続数には、現在アクティブな永続的接続および非永続的接続と、アイドルな永続的接続が含まれます。使用可能なhttpdサーバー・スレッドがない場合、接続リクエストはスレッドが使用可能になるまでTCP/IPシステムのキューに入れられます。最終的には、クライアントが接続を終了します。

Oracle HTTP Serverへの着信接続を処理するサーバー・プロセスの数、および1プロセス当たりのスレッドの数(ThreadsPerChild)を定義できます。ThreadsPerChildプロパティには、サーバー(子)・プロセスの下に作成可能なスレッドの数の上限を指定します。

ノート:

ThreadsPerChild、StartServers、ServerLimitの各プロパティは、MaxRequestWorkers設定と相互に関係しています。MaxRequestWorkersで指定した数の接続を得るには、これらのプロパティをすべて正しく設定する必要があります。すべてのHTTP構成プロパティの説明は、表6-1を参照してください。

親トピック: サーバー接続制限の設定

KeepAliveの設定

永続的なHTTP接続(KeepAlive)は、接続リクエストの処理中でなくても、接続期間中はhttpd子プロセス(スレッド)を消費します。

十分なキャパシティがある場合は、KeepAliveを有効にする必要があります。永続的な接続を使用することで、パフォーマンスが向上し、HTTP接続の再確立によるCPUリソースの浪費が回避されます。通常、KeepAliveパラメータの変更は不要です。

ノート:

永続的な接続に対するデフォルトの最大リクエスト数は100です。これはhttpd.confファイルのMaxKeepAliveRequestsディレクティブで指定されています。デフォルトでは、サーバーはクライアントからのリクエストを15秒間待ってから接続をクローズします。これはhttpd.confファイルのKeepAliveTimeoutディレクティブで指定されています。

親トピック: サーバー接続制限の設定

HTTP Serverモジュールのチューニング

Oracle HTTP Server (OHS)は、mod_wl_ohsモジュールを使用して、基礎となるWeblogic ServerまたはWeblogic Serverクラスタへリクエストを転送します。mod_wl_ohsモジュールの構成の詳細は、configディレクトリのmod_wl_ohs.confファイルで確認できます。

『Oracle HTTP Serverの管理』の「Oracle HTTP Serverモジュールの理解」を参照してください。

親トピック: サーバー接続制限の設定

接続プールの構成

接続プールは、Javaランタイムごとに設定および管理されます。接続は異なるランタイム間で共有されません。接続プールを使用する場合、設定を変更する必要はありません。構成が必要なのは、プールをカスタマイズする場合のみです。たとえば、プールのサイズやプールされる接続のタイプを制御する場合などです。

接続プーリングは、プログラムの起動時にシステム・プロパティの数を使用して構成します。これらは環境プロパティではなくシステム・プロパティであるため、すべての接続プーリング・リクエストに作用します。

データベースを使用するアプリケーションの場合、データ・ソースに関連付けられている接続プールの接続数を制限すると、パフォーマンスが向上します。MaxCapacity属性を使用してOracle Application Serverからのデータベース・リクエストを制限することで、受信リクエストが原因でデータベースが飽和状態にならないようにします。そのため、データベース・アクセスが原因でOracle Application Server層のリソースが過負荷状態になることもありません。

接続プールのMaxCapacity属性は、接続プールに作成できる接続の最大数を示します。デフォルトでは、MaxCapacity属性の値は15に設定されています。最適なパフォーマンスを得るには、データベースのパフォーマンス特性に適した数値をMaxCapacity属性に指定してください。

オープンしているデータベース接続の総数を、データベースで処理可能な数に制限することは、チューニングの際の重要な考慮事項です。データベースが、すべてのデータ・ソースのMaxCapacityオプションで指定されている値の合計と同じ数以上の接続をオープンできるよう構成します(このオプションはデータベースにアクセスするすべてのアプリケーションで指定されています)。

接続プールのオプションの詳細は、『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のJDBCデータ・ソース: コンフィグレーション: 接続プールに関する項および『Oracle WebLogic Server JDBCデータ・ソースの管理』のデータ・ソース接続プールのチューニング・オプションに関する項を参照してください。

親トピック: 同時実行性の制御

WebLogic Serverスレッド・プールのチューニング

デフォルトでは、WebLogic Serverで使用されるスレッド・プールは1つです。すべてのタイプの作業は、このスレッド・プールで実行されます。WebLogic Serverは、ワーク・マネージャを使用し、ユーザー定義ルールおよびランタイム・メトリック(リクエストの実行に要する実際の時間や、リクエストがプールに入る頻度とプールを出る頻度など)に基づいて処理の優先度を決定します。共通のスレッド・プールを管理するデフォルトのワーク・マネージャが存在します。

スループットを最大にするために、共通のスレッドプールのサイズが自動的に変更されます。WebLogic Serverでは、履歴に基づいてスループットを長期的にモニターし、スレッド数の調整が必要かどうかを判断しています。たとえば、履歴のスループット統計で、スレッド数が増えるとスループットも増えることが示されている場合、WebLogicはスレッド数を増やします。同様に、スレッド数が減ってもスループットは減らなかったことが示されている場合、WebLogicはスレッド数を減らします。

WebLogic Serverのスレッド・プールのサイズは自動的に設定されるため、チューニングの必要はないことがほとんどです。ただし、特殊な要件がある場合は、管理者がカスタム・ワーク・マネージャを構成して、同様のパフォーマンス要件、可用性要件または信頼性要件を持つリクエスト・セットごとに、スレッド・プールをきめ細かく管理できます。カスタム・ワーク・マネージャでは、保留中の作業の割当て方法に関する優先度およびガイドラインを定義できます。たとえば、最小スレッド数または最大スレッド数に対する制約や、WebLogic Serverがリクエストを拒否し始めるまでにキューに入れる、または実行することのできるリクエストの総数に対する制約を指定します。

ワーク・マネージャを使用してスレッド管理をカスタマイズする必要があるかどうかは、次のガイドラインを基に判断してください。

デフォルトのフェア・シェアが不十分です。

通常、これが該当するのは、特定のアプリケーションに他のアプリケーションより高い優先度を付ける場合です。
レスポンス時間の目標値が必要です。
最小スレッド数制約を指定して、サーバーのデッドロックを回避する。
アプリケーションでMDBを使用している。

MDBに割り当てるサーバー・スレッド・リソースを明確に定義して、それをMDBに確実に使用させる場合や、MDBの同時実行性をチューニングする場合は、最大スレッド数制約が指定されたカスタム・ワーク・マネージャを参照するように、ほとんどのMDBが変更されます。一般に、カスタム・ワーク・マネージャが便利なのは、複数のMDBデプロイメントが存在する場合や、特定のMDBが多くのスレッドを必要とする場合です。

ノート:

カスタム・ワーク・マネージャを使用してスレッド管理をカスタマイズする方法、およびカスタム・ワーク・マネージャを使用する必要があるかどうかの判断の詳細は、次のドキュメントを参照してください。

『Oracle WebLogic Serverのパフォーマンスのチューニング』のプール・サイズのチューニングに関する項
『Oracle WebLogic Serverのパフォーマンスのチューニング』のスレッド管理に関する項
『Oracle WebLogic Serverのパフォーマンスのチューニング』のMDBスレッド管理に関する項
『Oracle WebLogic Serverサーバー環境の管理』のワーク・マネージャを使用したスケジュール済作業の最適化に関する項
『Oracle WebLogic Serverサーバー環境の管理』の過負荷の回避と管理に関する項

Oracle WebLogic管理コンソールを使用して、スレッド・プールのステータスの概要(アクティブ・スレッド数、合計スレッド数、キューの長さなど)を確認します。コンソールでは、「モニタリング」ページの「ワークロード」タブから、アプリケーションに設定したワーク・マネージャ・メトリックも確認できます。表示されるメトリックは、保留中リクエストの数や完了したリクエストの数などです。

『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のサーバー: モニター: スレッドに関する項、およびデプロイメント: モニター: ワークロードに関する項を参照してください。

ワーク・マネージャおよびスレッド・プールのメトリックは、Oracle Fusion Middleware Controlからも確認できます。

親トピック: 同時実行性の制御

ロギング・レベルの設定

ログに記録される情報の量は、パフォーマンスに大きく影響することがあります。

アプリケーションがログに記録する情報の量は、環境の構成およびアプリケーション・コードのインストゥルメント状況によって異なります。パフォーマンスを最大化するには、デフォルトのINFOレベルより高いロギング・レベルを設定しないでください。ロギング設定がデフォルト・レベルと異なる場合は、最適なパフォーマンスが得られるよう、ロギング・レベルをデフォルトに戻します。

アプリケーションおよびサーバーのロギング・レベルを設定したら、デバッグ・プロパティやアプリケーション・レベルのその他のデバッグ・フラグが適切なレベルに設定されているか、または無効になっていることを確認します。パフォーマンスへの影響を回避するには、ロギング・レベルを、より多くの診断メッセージが生成されるレベル(FINEレベルまたはTRACEレベル)に設定しないでください。

コンポーネントごとに、特定の推奨ロギング・レベルがあります。

親トピック: 主なパフォーマンス分野