ヘッダーをスキップ
Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド
11g リリース1 (11.1.1)
B61006-10
  目次へ移動
目次
前
前 		 次
次		  

24 Oracle Unified Directoryのパフォーマンス・チューニング

この章では、Oracle Unified Directoryのチューニングおよびサイズ設定のガイドラインを示します。この章の内容は、次のとおりです。

24.1 Oracle Unified Directoryについて

Oracle Unified Directoryは、大規模なデプロイメントへの対応、優れたパフォーマンスの提供、高い拡張性、および簡単なデプロイ、管理および監視を実現するために設計された、包括的な次世代ディレクトリ・サービスです。

24.2 パフォーマンスに関する考慮事項

Oracle Unified Directoryの目標は、高いパフォーマンスおよびスケーラビリティを実現することです。デフォルトのサーバー構成およびJVM設定でも、サーバーで優れた結果を実現できる可能性はありますが、若干の基本的なチューニングを行うことで、多くの場合、パフォーマンスが大幅に向上します。

Oracle Unified Directoryのデフォルト設定は、制限されたリソースを使用して機器を稼働させている評価担当者および開発者を対象としています。Oracle Unified Directoryを本番環境にデプロイする場合、Java仮想マシン(JVM)およびサーバー構成に対して若干の初期チューニングを行うことによって、スケーラビリティおよびパフォーマンスを向上(特に書込み操作の場合)させることができます。

また、パフォーマンス・チューニングの戦略は、ディレクトリ・サーバーとプロキシ・サーバーのどちらを実行しているかによって異なります。この項では、サーバーの使用状況に基づいてチューニングを検討する必要がある、いくつかの領域について説明します。具体的なチューニング・パラメータおよびその説明は、第24.4項「チューニングに関する基本的な考慮事項」に記載されています。

また、特定のデプロイメント・シナリオでは、次の項目によってパフォーマンスが向上する場合があります。

24.3 Unified Directoryのパフォーマンスの監視

ここでは、Unified Directoryのパフォーマンス情報を収集するために使用できる、主要な監視ツールの概要について説明します。


注意:

Oracle Unified Directoryでは拡張可能な監視フレームワークが提供されます。Oracle Unified Directoryのパフォーマンスは、Enterprise Manager Grid Controlプラグインを使用して監視することもできます。詳細は、Oracle Unified Directory用システム監視プラグイン・ユーザーズ・ガイドを参照してください。

24.3.1 ログ・ファイルの調査

Oracle Unified Directoryでは、アクセス・ログ、監査ログ、エラー・ログ、デバッグ・ログ、oud-setupログ、server.outログ、レプリケーション修復ログなど、様々なタイプのログが提供されます。レプリケーション修復ログは読取り専用であり、レプリケーションの競合解決を有効にする場合のみ使用できます。

パフォーマンスの問題がサーバーとクライアントのどちらに関連しているかを迅速に特定するには、INSTANCE_DIR/OUD/logs/accessにあるアクセス・ログを確認します。アクセス・ログには、ディレクトリ・サーバーによって処理された操作のタイプに関する情報が記録されます。アクセス・ログはデフォルトで提供されます。

このログには、次の形式のエントリが含まれます。

[09/Sep/2009:15:36:18 +0200] SEARCH RES conn=1 op=16 msgID=17 
  result=0 nentries=1 etime=1

etimeフィールドの値は、サーバーがリクエストの処理に費やした時間(ミリ秒単位)です。一般的には、etimesの値が大きい場合、サーバー側で問題が発生しています(通常この問題は、適切なパフォーマンス・チューニングおよび索引付けを行うことによって解決できます)。パフォーマンスの問題が発生しているが、etimesの値が小さい場合は、クライアント・アプリケーションに問題がある可能性が高くなります。

24.3.2 LDAPを使用したサーバーの監視

Oracle Unified Directory管理者ガイドの次の項には、Lightweight Directory Application Protocol (LDAP)を使用したサーバーの監視手順が詳しく記載されています。

  • cn=monitorエントリを使用した監視情報の表示に関する項

  • manage-tasksコマンドを使用した監視に関する項

  • JConsoleを使用したサーバーの監視に関する項

24.3.3 SNMPを使用したサーバーの監視

Oracle Unified Directoryでは、管理情報ベース(MIB) 2605サポートのSimple Network Management Protocol (SNMP)接続ハンドラを含むjarファイル拡張が提供されます。この拡張には、SNMP接続ハンドラ、MIB 2605オブジェクトとSNMPリクエストをサポートするために必要なクラス、およびSNMPマネージャによるサーバー監視情報へのアクセスを可能にするSNMPアダプタが含まれます。

24.4 チューニングに関する基本的な考慮事項

次の項では、Oracle Unified Directoryのチューニング中にも考慮する必要がある、基本的なチューニング構成について説明します。

24.4.1 Java仮想マシン設定のチューニング

第2章「Java仮想マシン(JVM)のチューニング」で説明したとおり、JAVA_ARGS環境変数を使用して、JVMに渡すことができるグローバル構成引数を提供するか、java.propertiesファイルを使用できます。javaコマンドで使用できる引数はすべて、どちらの方法でも使用できます。

次の表では、Oracle Unified Directory用にチューニングできる主なJVMオプションについて説明します。これらのうち、一部の設定はSun JVMにのみ適用されますが、類似した設定がJRockitに適用される場合があります。

パラメータ 説明 OUDをディレクトリ・サーバーとして使用する場合 OUDをプロキシ・サーバーとして使用する場合

-server

常にクライアントJVMではなくサーバーJVMを使用します。クライアントVMは、実行時間が短いプロセス用に最適化されているため、できるかぎり迅速に起動する必要があります。サーバーVMはウォームアップに時間がかかりますが、処理速度はクライアントVMよりも高速です。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-d32または-d64

次のように、32ビットまたは64ビット・バージョンのJVMを選択します。

  • -d32を指定すると、JVMヒープのサイズが3.5GBよりも小さい場合、パフォーマンスが向上します。

  • -XX:+UseCompressedOopsは、JVMヒープのサイズが3.5GBから31GBの場合に指定します。

  • -d64は、JVMヒープのサイズが32GBを超える場合に指定します。

使用するJVMのバージョンは、ヒープ・サイズによって異なります。

グローバル索引を使用する場合以外は適用されません。それ以外で、プロキシ・サーバーが4GBを超えるヒープを必要とすることはほとんどありません。

ほとんどの場合、32ビット・バージョンのJVMを使用します。

-XX:+UseCompressedOops

このオプションは、64ビットのJVMを使用し、ヒープ・サイズが32GB未満の場合に使用します。

説明に従ってこのパラメータを設定します。

64ビットのJVMが必要になるため、適用されません。

-Xms (初期ヒープ・サイズ)

-Xmx (最大ヒープ・サイズ)

このパラメータによって、JVMで使用できる初期ヒープ・サイズおよび最大ヒープ・サイズが設定されます。

ヒープ・サイズを増やすとパフォーマンスが向上する場合がありますが、設定した値が大きすぎる場合、フル・ガベージ・コレクションを実行するための一時停止時間が長くなるという悪影響が生じる可能性があります。通常、初期サイズおよび最大サイズは同じ値に設定する必要があります。

パフォーマンスを最大にするには、DB全体をメモリー内にキャッシュできるようにヒープのサイズを設定します。通常は、サーバーの実行に必要なヒープを割り当て、残りをDBキャッシュに割り当てます。

CMSを古い世代のガベージ・コレクタとして使用する場合、ヒープ・サイズを計算するときに、DBキャッシュによって占有されるサイズ(またはヒープの割合)と整合がとれるよう、-XX:CMSInitiatingOccupancyFractionプロパティを考慮する必要があります。

CMSInitiatingOccupancyFractionを55に設定する場合、DBキャッシュの割合は50に設定する必要があります。また、10GBのディスク上にデータベースがある場合、データベース全体をDBキャッシュ内に収めるには、22GB以上のヒープが必要になります。

説明に従ってこのパラメータを設定します。

例:

-Xmx31G

-Xms31G

説明に従ってこのパラメータを設定します。

例:

-Xmx3500M

-XX:NewSize

ヒープ領域全体は、古い世代と若い世代に分かれます。このパラメータによって、若い世代のサイズが設定されます。残りのメモリー(古い世代)に対しては、DBキャッシュに加えて、若干のオーバーヘッドを保持できるだけのサイズを確保する必要があります。

説明に従ってこのパラメータを設定します。

例:

-XX:NewSize=512M

説明に従ってこのパラメータを設定します。

例:

-XX:NewSize=2G

-XX:+UseConcMarkSweepGC

並行Mark Sweep (CMS)ガベージ・コレクタを使用します。このオプションを使用すると、JVMにおけるLDAP操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。一時停止時間が長くなることを許容できない場合は、このオプションを使用してください。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-XX:CMSInitiatingOccupancyFraction=<percentage>

CMSガベージ・コレクションが開始されるレベルを指定します。デフォルト値は約68%です。デフォルト値以外の割合を設定する場合は、この値を使用してください。

CMSを古い世代のガベージ・コレクタとして使用する場合、ヒープ・サイズを計算するときに、DBキャッシュによって占有されるサイズ(またはヒープの割合)と整合がとれるよう、CMSプロパティ-XX:CMSInitiatingOccupancyFractionを考慮することが重要です。

CMSInitiatingOccupancyFractionを55に設定する場合、DBキャッシュの割合は50に設定する必要があります。また、10GBのディスク上にデータベースがある場合、データベース全体をDBキャッシュ内に収めるには、22GB以上のヒープが必要になります。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-XX:+UseCMSInitiatingOccupancyOnly

-XX:CMSInitiatingOccupancyFraction=60を指定した場合に、-XX:UseCMSInitiatingOccupancyOnlyを追加します。これにより、CMSコレクションは、引き続きそのしきい値に達する前に開始されます。-XX:CMSInitiatingOccupancy=60を削除し(デフォルト値の69%を使用します)、-XX:UseCMSInitiatingOccupancyOnlyという行を追加することを検討してください。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-XX:+UseBiasedLocking

競合があまり発生しないことが予想される場合に、サーバー内で発生するロックのパフォーマンスを向上させます。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-XX:LargePageSizeInBytes=256m

メモリー内に格納する情報に対して、サイズの大きいページを使用します。

注意: この引数は主に、UltraSPARC T1プロセッサを使用するシステムに適用されます。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-XX:+CMSScavengeBeforeRemark

注釈の一時停止時間を短縮するために、注釈の前に簡単なコレクションを実行します。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

-XX:+UseNUMA

注意: このオプションは、UltraSPARC Txプロセッサでのみ使用する必要があります。

説明に従ってこのパラメータを設定します。

説明に従ってこのパラメータを設定します。

24.4.2 サーバー構成のチューニング

サーバーの様々なコンポーネントをチューニングして、特定のシナリオにおけるパフォーマンスを改善できます。パフォーマンスのチューニングに関する推奨事項のほとんどは、予想されるワークロード、格納されるデータのタイプ、使用可能なハードウェアとリソースなど、いくつかの可変要素に依存します。チューニングに関する次の一般的な推奨事項によって、特定のデプロイメントにおけるサーバーのパフォーマンスを改善できます。

24.4.2.1 Oracle Berkeley DB Java Editionのチューニング・パラメータ

Oracle Berkeley DB Java Editionは、埋込み可能なオープン・ソースのトランザクション・ストレージ・エンジンです。Oracle Berkeley DB Java Editionのアーキテクチャでは、非常に高いパフォーマンスが実現され、読取りの集中するワークロードと書込みの集中するワークロードを同時に実行できます。

次のBerkeley DB Java Edition (JE)チューニング・パラメータを使用して、パフォーマンスをチューニングできます。

パラメータ 説明

db-cache-percentおよび

db-cache-size

これらのプロパティを使用して、データベース・キャッシュで使用されるメモリーの量を構成します。db-cache-sizeは、ディレクトリのサイズと使用可能なメモリーの量に依存します。

キャッシュ・オプションには、次の2つがあります。

  • JVMヒープ内にすべてキャッシュします。

    ディレクトリのサイズが小さく、使用可能なメモリーの量が十分である場合は、db-cache_sizeをチューニングしてノード全体を含める必要があります。このキャッシュ・モードではレスポンス時間が一定になり、ディスクI/Oが減少しますが、大きいサイズのJVMヒープが必要になるため、ガベージ・コレクションに影響を与える可能性があります。

  • JVMヒープ内に一部をキャッシュし、残りをファイル・システム・キャッシュ内にキャッシュします。

    ディレクトリのサイズが大きすぎて、すべてのノードをメモリー内に格納できない場合、db-cache-sizeをチューニングして、上部の内側にあるノード(UpperIN)と下部の内側にあるノード(BIN)のみを含める必要があります。このキャッシュ・モードでは、ディスクI/Oが減少し、ヒープ・サイズの大きさが原因で発生した問題の一部が解決される可能性がありますが、処理速度が低下する場合があり、決定性のレスポンス時間も若干低下します(パフォーマンスが低下する割合は、JVM内にキャッシュされるDBのサイズに比例します)。

    内側のノードのサイズは、DbCacheSizeユーティリティを使用して計算できます。詳細は、「JEキャッシュ・サイズの予測」を参照してください。

db-cache-sizeを正確に設定するには、まずインポート後にデータベースのおおよそのサイズを特定する必要があります。たとえば、userRootバックエンドへのインポートを行った後、次のコマンドを(UNIXシステム上で)実行してデータベースのサイズを確認します。

$ cd INSTANCE_DIR/OUD/db
$ du -sk userRoot/
910616 userRoot/

Windowsシステム上では、同等の手順を使用してデータベースのサイズを確認します。データベースのサイズは静的ではなく、変更が加えられたときの最初のインポート後に増加する場合があります。

JVMヒープを2GBに設定し(-Xms2g -Xmx2g)、db-cache-percentを50に設定すると、DBキャッシュで1GBのメモリーが使用されます。

je.checkpointer.highPriority

trueの場合、チェックポインタでは、短い間隔でチェックポイントを完了するために、より多くのリソースが使用されます。Bツリーのラッチは保持され、他のスレッドはより長い期間ブロックされます。ログ・クリーナ・レコードの移行は、削除中およびチェックポイント中にゆっくり実行される(CLEANER_LAZY_MIGRATIONを参照)のではなく、クリーナ・スレッドによって実行されます。trueに設定された場合、チェックポイント中のアプリケーションのレスポンス時間が長くなり、構成済ログの使用率を維持するために、より多くのクリーナ・スレッドが必要になる場合があります。

このプロパティをfalseに設定すると、スループットが向上し、レスポンス時間が短縮されます。

preload-time-limit

起動時にデータベースの内容をメモリー内に事前ロードするようにサーバーを構成できます。データベースのサイズが大きい場合、データベース・キャッシュを事前ロードすることによって、サーバー起動後のウォームアップ時間を短縮できます。

db-directory

十分なサイズのストレージを備えた高速なファイル・システム上でデータベースを保持します。このファイル・システムとは異なる場所にアクセス・ログを配置する必要があります。デフォルトでは、データベースのサイズは元の2倍になります。たとえば、インポート後のデータベースのサイズが1GBである場合、ファイル・システムでは2GB以上が使用可能になっている必要があります。

db-evictor-lru-only

このプロパティを使用して、データベース・キャッシュによる情報の保持方法を制御します。この値をfalseに設定すると、内部ノードがキャッシュ内で保持されるため、JEキャッシュによって保持されるデータベースの内容の割合が低い場合のみ、パフォーマンスが向上します。

db-txn-durability

このプロパティを使用して、書込み操作の永続性を構成します。永続性が低下すると、書込みのパフォーマンスは向上する場合がありますが、JVMやシステムのクラッシュ時にデータが失われる可能性が高くなります。このプロパティの値は、次のいずれかです。

  • write-to-disk。すべてのデータが同期的にディスクに書き込まれます。

  • write-to-fs。データはすぐにファイル・システムに書き込まれますが、ディスクにフラッシュされるまでファイル・システム内に留まる場合があります。

  • write-to-cache。データは内部バッファに書き込まれ、ファイル・システムにフラッシュされた後、必要な場合はディスクにフラッシュされます。

db-log-file-max

このプロパティを使用して、JEログ・ファイルのサイズを制御します。ファイル・サイズを増やすと書込みのパフォーマンスが向上する場合がありますが、目標とする使用率の維持がより難しくなる可能性があります。

db-num-cleaner-threads

およびdb-cleaner-min-utilization

これらのプロパティは、クリーナの動作を制御することによって、データベース・サイズの増加を抑え、書込みの高いスループットを維持します。不要になった古いレコードはクリーンアップされます。チューニングされていない場合、クリーンアップ・プロセスはパフォーマンスに影響を与える可能性があります。

db-num-lock-tables

多くのCPUを搭載したシステムでは、このプロパティによってデータベース・ロック・マネージャ内の同時実行性が向上する場合があります。

24.4.2.2 コア・サーバーのチューニング・パラメータ

次に示すコア・サーバーのチューニング・パラメータを使用して、パフォーマンスをチューニングできます。

パラメータ 説明

num-request-handlers

このプロパティを構成して、LDAP接続ハンドラで(有効になっている場合はLDAPS接続ハンドラでも)クライアント・リクエストのデコードに複数のスレッドを使用できます。多くのCPUを搭載したシステムでスレッド数を増やすと、パフォーマンスが向上する場合があります。大まかに言えば、このプロパティはCPU数の4分の1(最大値は12)に設定する必要があります。

keep-statsプロパティを無効にすると、接続ハンドラのロック競合が減少する場合があります。

num-worker-threads

このプロパティのデフォルト値は、CPU数の2倍です。ほとんどのデプロイメントには、この値で十分です。

log-file

アクセス・ログのパブリッシャを高速ファイル・システム上に配置するか、enabledプロパティをfalseに設定して完全に無効にします。

24.5 チューニングに関する高度な推奨事項

次に示す追加の推奨事項によって、特定のシナリオにおけるパフォーマンスが向上する場合があります。

  前
前 		 次
次
  目次へ移動
目次