| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-02 |
|
 前 |
 次 |
Oracle Unified Directoryの目標は、高いパフォーマンスおよびスケーラビリティを実現することです。デフォルトのサーバー構成およびJVM設定でも、サーバーで優れた結果を実現できる可能性はありますが、若干の基本的なチューニングを行うことで、多くの場合、パフォーマンスが大幅に向上します。
Oracle Unified Directoryのデフォルト設定は、制限されたリソースを使用して機器を稼働させている評価担当者および開発者を対象としています。Oracle Unified Directoryを本番環境にデプロイする場合、Java仮想マシン(JVM)およびサーバー構成に対して若干の初期チューニングを行うことによって、スケーラビリティおよびパフォーマンスを向上(特に書込み操作の場合)させることができます。
この章では、次のトピックを取り扱います:
パフォーマンスの問題がサーバーとクライアントのどちらに関連しているかを迅速に特定するには、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の値が小さい場合は、クライアント・アプリケーションに問題がある可能性が高くなります。
包括的な監視情報は、cn=monitorエントリにあります。詳細は、第29章「Oracle Unified Directoryの監視」を参照してください。Oracle Unified Directoryのパフォーマンスは、Enterprise Manager Grid Controlプラグインを使用して監視することもできます。詳細は、Oracle Unified Directory用システム監視プラグイン・ユーザーズ・ガイドを参照してください。
パフォーマンス・チューニング戦略は、ディレクトリ・サーバーとプロキシ・サーバーのどちらを実行しているかによって異なります。
特定のデプロイメント・シナリオでは、次の項目によってパフォーマンスが向上する場合があります。
Javaのバージョン。提供されているJava Runtime Environment (JRE)の最新リリースを使用します。Oracle Unified Directoryは、Java SE 6および7と連携して動作するように設計されています。
環境変数。サーバーはOPENDS_JAVA_HOME環境変数を使用して、インストール済のJREを指します。複数のバージョンのJavaがシステムにインストールされている場合は、目的のインストールのルートを指すようにJAVA_HOME環境変数を設定します。これにより、Oracle Unified Directoryではない他のアプリケーションが、JAVA_HOME変数によって指定されたバージョンのJREを使用できるようになります。
サーバー用のJREインストールを指定するには、次のいずれかを実行します:
dsjavapropertiesコマンドを使用して、適切な環境変数を設定します。
詳細は、「dsjavaproperties」を参照してください。
OPENDS_JAVA_BIN環境変数を(JAVAのバイナリ・パスを使用して)設定します。
OPENDS_JAVA_HOME環境変数を(JAVAのインストール・パスを使用して)設定します。
JAVA_ARGS環境変数を使用して、JVMに渡すことができるグローバル構成引数を提供するか、java.propertiesファイルを使用できます。javaコマンドで使用できる引数はすべて、どちらの方法でも使用できます。
最適なパフォーマンスを実現するためにJVMをチューニングして、Oracle Unified Directoryアプリケーションを強固かつ応答を早くすることをお薦めします。ヒープ・サイズをチューニングすることによってJVMをチューニングできます。ヒープ・サイズは、次のように分割されます:
若い世代: PDUやローカル変数などの操作を含みます。
古い世代: JEデータベース・キャッシュやエントリ・キャッシュなどのOracle Unified Directoryキャッシュを含みます。
永続世代: 定数およびクラスを含みます。
Oracle Unified Directoryがディレクトリ・サーバー・モードの場合、次のデータベース・キャッシュ・オプションのいずれかを実行できます:
データベース・キャッシュのデータベース全体をキャッシュします。これによって最適なパフォーマンスが与えられますが、キャッシュ・ウォームアップが長くなり、ヒープ・サイズが大きくなります。
データベース・キャッシュでデータベースのBツリー(上位ノードおよび内部ノード)の内部ノードのみをキャッシュし、残りのRAMをファイル・システム・キャッシュ用に保持します。これによってパフォーマンスが向上し、ウォームアップが短くなり、ヒープ・サイズが小さくなります。非常に大きいデプロイ(50MBytesエントリ超)用にお薦めします。小規模および中規模のデプロイにお薦めします。
詳細は、第30.4項「データベース・キャッシュ・サイズの決定」を参照してください。
|
注意: プロキシ・モードでは、グローバル索引を使用した配布に大きい古い世代を使用します。 |
詳細は、「dsjavaproperties」を参照してください。
JVMのチューニングに関する追加情報は、Javaパフォーマンスのドキュメント(http://java.sun.com/docs/performance/)を参照してください。Javaチューニングのホワイト・ペーパー(http://java.sun.com/performance/reference/whitepapers/tuning.html)およびガベージ・コレクションのチューニング(http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136373.html)のドキュメントが特に役に立ちます。
次の表では、主なJVMチューニング可能オプションについて説明します。
| パラメータ | 説明 |
|---|---|
|
|
常にクライアントJVMではなくサーバーJVMを使用します。クライアントVMは、実行時間が短いプロセス用に最適化されているため、できるかぎり迅速に起動する必要があります。サーバーVMはウォームアップに時間がかかりますが、長い目で見れば高速です。 |
|
|
次のように、32ビットまたは64ビット・バージョンのJVMを選択します:
|
|
|
このオプションは、64ビットのJVMを使用し、ヒープ・サイズが32GB未満の場合に使用します。 |
|
|
このパラメータによって、JVMで使用できる初期ヒープ・サイズおよび最大ヒープ・サイズが設定されます。ヒープ・サイズを増やすとパフォーマンスが向上する場合がありますが、設定した値が大きすぎる場合、フル・ガベージ・コレクションを実行するための一時停止時間が長くなるという悪影響が生じる可能性があります。通常、初期サイズおよび最大サイズは同じ値に設定する必要があります。 パフォーマンスを最大化するには、DB全体をメモリー内にキャッシュできるようにヒープのサイズを設定します。通常は、サーバーの実行に必要なヒープを割り当て、残りをDBキャッシュに割り当てます。 たとえば、Oracle Unified Directoryインスタンスのヒープ・サイズを
CMSを古い世代のガベージ・コレクタとして使用する場合、ヒープ・サイズを計算するときに、DBキャッシュによって占有されるサイズ(またはヒープの割合)と整合がとれるよう、
|
|
|
ヒープ領域全体は、古い世代と若い世代に分かれます。このパラメータによって、若い世代のサイズが設定されます。残りのメモリー(古い世代)に対しては、DBキャッシュに加えて、若干のオーバーヘッドを保持できるだけのサイズを確保する必要があります。 |
|
|
並行Mark Sweep (CMS)ガベージ・コレクタを使用します。このオプションを使用すると、JVMにおけるLDAP操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。一時停止時間が長くなることを許容できない場合は、このオプションを使用してください。 |
|
|
CMSガベージ・コレクションが開始されるレベルを指定します。デフォルト値は約68%です。デフォルト値以外の割合を設定する場合は、この値を使用してください。 |
|
|
競合があまり発生しないことが予想される場合に、サーバー内で発生するロックのパフォーマンスを向上させます。 |
|
|
メモリー内に格納する情報に対して、サイズの大きいページを使用します。この引数は主に、UltraSPARC T1プロセッサを使用するシステムに適用されます。 |
|
|
多数のCPUを持つシステムにおいて特に便利なパラレル・ガベージ・コレクションをシステムが使用する必要があることを指定します。 |
|
-XX:+UseParallelOldGC |
JVMが古い世代に対してパラレル・ガベージ・コレクションを使用する必要があることを指定します。 |
|
|
パラレル・ガベージ・コレクション実行時にJVMが8個のスレッドを使用する必要があることを指定します。デフォルトは、CPU数と同じ数のスレッドを使用することですが、非常に多数のCPUがあるシステムまたはCMTベースのシステム(UltraSPARC T1プロセッサを使用するシステムなど)ではこれが不適切である可能性があります。 |
Oracle Unified Directoryインスタンスをインストールまたは構成して初期化した場合、<OUD_INSTANCE_DIR>/OUD/db/userRootディレクトリのサイズを測定することによって、データベース・キャッシュ・サイズの要件を決定できます(Oracle Unified DirectoryインスタンスのデータベースがuserRootというデータベース1つのみであることが前提)。
Oracle Unified Directoryインスタンスが構成または初期化されていない場合、DbCacheSizeユーティリティ(com.sleepycat.je.util)を使用して、1つの索引ファイルまたはユーザー・データを含むファイルの内部ノードを格納するために必要なメモリーを決定できます。
DbCacheSizeユーティリティの使用法の詳細は、このJavadocページ(http://docs.oracle.com/cd/E17277_02/html/java/com/sleepycat/je/util/DbCacheSize.html)を参照してください。
たとえば、10バイトの索引および平均キー・サイズを備えた4KBの1000万エントリは次のようになります:
[oud@oel5 bin]$ java -jar -XX:+UseCompressedOops /space/Middleware/Oracle_OUD1/lib/je.jar DbCacheSize -records 10000000 -key 10 -data 4000
=== Database Cache Size ===
Minimum Bytes Maximum Bytes Description
--------------- --------------- -----------
259,725,752 317,907,896 Internal nodes only
40,721,011,192 40,779,193,336 Internal nodes and leaf nodes
=== Internal Node Usage by Btree Level ===
Minimum Bytes Maximum Bytes Nodes Level
--------------- --------------- ---------- -----
256,180,800 313,709,120 112,360 1
3,503,312 4,149,456 1,262 2
38,864 46,032 14 3
2,776 3,288 1 4
4KBの1000万エントリのデプロイでは、データベース・キャッシュにフル・ユーザー・データを格納するために37GBが必要です(4KBエントリおよびデータベースのBツリーの内部ノード)。データベース・キャッシュに内部ノードのみを格納する場合、索引ごとに303MBが必要です(10索引では3GB)。
サーバーの様々なコンポーネントをチューニングして、特定のシナリオにおけるパフォーマンスを改善できます。パフォーマンスのチューニングに関する推奨事項のほとんどは、予想されるワークロード、格納されるデータのタイプ、使用可能なハードウェアとリソースなど、いくつかの可変要素に依存します。
チューニングに関する次の一般的な推奨事項によって、特定のデプロイメントにおけるパフォーマンスを改善できます。
次のBerkeley DB JEチューニング・パラメータを使用して、パフォーマンスをチューニングできます:
| パラメータ | 説明 |
|---|---|
|
|
trueの場合、チェックポインタでは、短い間隔でチェックポイントを完了するために、より多くのリソースが使用されます。Bツリーのラッチは保持され、他のスレッドはより長い期間ブロックされます。ログ・クリーナ・レコードの移行は、削除中およびチェックポイント中にゆっくり実行される(CLEANER_LAZY_MIGRATIONを参照)のではなく、クリーナ・スレッドによって実行されます。trueに設定された場合、チェックポイント中のアプリケーションのレスポンス時間が長くなり、構成済ログの使用率を維持するために、より多くのクリーナ・スレッドが必要になる場合があります。 このプロパティをfalseに設定すると、スループットが向上し、レスポンス時間が短縮されます。 |
|
|
起動時にデータベースの内容をメモリー内に事前ロードするようにサーバーを構成できます。データベースのサイズが大きい場合、データベース・キャッシュを事前ロードすることによって、サーバー起動後のウォームアップ時間を短縮できます。詳細は、Oracle Unified Directory構成リファレンスのローカルDBバックエンド構成に関する項を参照してください。 |
|
|
これらのプロパティを使用して、データベース・キャッシュが使用するメモリー量を構成します。最高のパフォーマンスを得るためには、データベース全体がデータベース・キャッシュに収まるようにサーバーを構成することを考慮します。 インポート後にデータベースのおよそのサイズを判定します。たとえば、
$ cd INSTANCE_DIR/OUD/db
$ du -sk userRoot/
910616 userRoot/
Windowsシステム上では、同等の手順を使用してデータベースのサイズを確認します。データベースのサイズは静的ではなく、変更が加えられたときの最初のインポート後に増加する場合があります。 JVMヒープを2GBに設定し(
レプリケーション・メタデータ、ユーザーおよびアプリケーションのために、データベースは時間の経過とともに非常に大きくなります。これは、インポート後のパフォーマンスに影響する場合があります。Oracle Unified DirectoryのJVMヒープ・サイズ(主に古い世代)をチューニングすることをお薦めします。 |
|
|
十分なサイズのストレージを備えた高速なファイル・システム上でデータベースを保持します。このファイル・システムとは異なる場所にアクセス・ログを配置する必要があります。デフォルトでは、データベースのサイズは元の2倍になります。たとえば、インポート後のデータベースのサイズが1GBである場合、ファイル・システムでは2GB以上が使用可能になっている必要があります。 |
|
|
このプロパティを使用して、データベース・キャッシュによる情報の保持方法を制御できます。この値を |
|
|
このプロパティを使用して、書込み操作の永続性を構成します。永続性が低下すると、書込みのパフォーマンスは向上する場合がありますが、JVMやシステムのクラッシュ時にデータが失われる可能性が高くなります。このプロパティの値は、次のいずれかです:
|
|
|
このプロパティを使用して、JEログ・ファイルのサイズを制御します。ファイル・サイズを増やすと書込みのパフォーマンスが向上する場合がありますが、目標とする使用率の維持がより難しくなる可能性があります。 |
|
および |
これらのプロパティは、クリーナの動作を制御することによって、データベース・サイズの増加を抑え、書込みの高いスループットを維持します。 |
|
|
多くのCPUを搭載したシステムでは、このプロパティによってデータベース・ロック・マネージャ内の同時実行性が向上する場合があります。 |
次に示すコア・サーバーのチューニング・パラメータを使用して、パフォーマンスをチューニングできます:
num-request-handlers
このプロパティを構成して、LDAP接続ハンドラで(有効になっている場合はLDAPS接続ハンドラでも)クライアント・リクエストのデコードに複数のスレッドを使用できます。多くのCPUを搭載したシステムでスレッド数を増やすと、パフォーマンスが向上する場合があります。大まかに言えば、このプロパティはCPU数の4分の1(最大値は12)に設定する必要があります。
keep-statsプロパティを無効にすると、接続ハンドラのロック競合が減少する場合があります。詳細は、Oracle Unified Directory構成リファレンスのLDAP接続ハンドラ構成に関する項を参照してください。
num-worker-threads
このプロパティのデフォルト値は、CPU数の2倍です。ほとんどのデプロイメントには、この値で十分です。
log-file
アクセス・ログのパブリッシャを高速ファイル・システム上に配置するか、enabledプロパティをfalseに設定して完全に無効にします。詳細は、Oracle Unified Directory構成リファレンスのファイル・ベース・アクセス・ログ・パブリッシャ構成に関する項を参照してください。
次に示す追加の推奨事項によって、特定のシナリオにおけるパフォーマンスが向上する場合があります。
エントリ・キャッシュの有効化。エントリ・キャッシュの有効化は、特にディレクトリのサイズが比較的小さい場合(たとえば、数十万エントリまで)に役立ちます。通常は、ソフト参照のエントリ・キャッシュよりもFIFOのエントリ・キャッシュの方が優れた結果を提供します。詳細は、Oracle Unified Directory構成リファレンスのエントリ・キャッシュ構成に関する項を参照してください。
大規模なデータベースの場合は、include-filterプロパティを使用して、特定のデータ・セットのみをキャッシュ内に格納することをお薦めします。静的グループをエントリ・キャッシュ内に格納すると、サーバーの全体的なパフォーマンスが大幅に向上する可能性があります。これにより、ACIの評価などで必要になるグループ・メンバーシップ参照の実行時間が短縮されます。
使用されていない仮想属性の無効化。1つ以上の仮想属性によって使用される機能が不要な場合、それらを無効にすると、エントリのデコード時のパフォーマンスが若干向上する可能性があります。詳細は、Oracle Unified Directory構成リファレンスの仮想属性構成に関する項を参照してください。
使用されていないアクセス・ロギングの無効化。アクセス・ロギングが不要な場合、サーバーのアクセス・ロガーを無効にすると、パフォーマンスが向上する可能性があります。詳細は、Oracle Unified Directory構成リファレンスのログ・パブリッシャ構成に関する項を参照してください。
使用されていないアクセス制御ハンドラの無効化。サーバー内のアクセス制御処理が不要な場合は、アクセス制御ハンドラのenabled構成プロパティをfalseに設定することによって、ハンドラを無効にできます。このプロパティはdsconfigを使用して設定できます。
ロック競合の削減。多くのCPUが搭載されたシステム(たとえば、コアごとにいくつかのハードウェア・スレッドを提供するチップマルチスレッド化(CMT)システム)では、org.opends.server.LockManagerConcurrencyLevelシステム・プロパティを、使用するワーカー・スレッドと同じ数に設定することによって、ロック競合を削減できます。
|
注意: このプロパティは、サーバー起動プロセスの非常に早い段階(サーバー構成へのアクセスよりも前)で必要になるため、JVMシステム・プロパティとして設定する必要があります。 |
