この章では、Oracle Unified Directoryのチューニングおよびサイズ設定のガイドラインを示します。この章の内容は、次のとおりです。
Oracle Unified Directoryは、大規模なデプロイメントへの対応、優れたパフォーマンスの提供、高い拡張性、および簡単なデプロイ、管理および監視を実現するために設計された、包括的な次世代ディレクトリ・サービスです。
Oracle Unified Directoryの目標は、高いパフォーマンスおよびスケーラビリティを実現することです。デフォルトのサーバー構成およびJVM設定でも、サーバーで優れた結果を実現できる可能性はありますが、若干の基本的なチューニングを行うことで、多くの場合、パフォーマンスが大幅に向上します。
Oracle Unified Directoryのデフォルト設定は、制限されたリソースを使用して機器を稼働させている評価担当者および開発者を対象としています。Oracle Unified Directoryを本番環境にデプロイする場合、Java仮想マシン(JVM)およびサーバー構成に対して若干の初期チューニングを行うことによって、スケーラビリティおよびパフォーマンスを向上(特に書込み操作の場合)させることができます。
また、パフォーマンス・チューニングの戦略は、ディレクトリ・サーバーとプロキシ・サーバーのどちらを実行しているかによって異なります。この項では、サーバーの使用状況に基づいてチューニングを検討する必要がある、いくつかの領域について説明します。具体的なチューニング・パラメータおよびその説明は、第24.4項「チューニングに関する基本的な考慮事項」に記載されています。
OUDがLDAPディレクトリ・サーバーとして使用される場合。ディレクトリ・サーバーとして使用される場合、次の方法でパフォーマンスを最大にできます。
データベース・キャッシュ・サイズ、事前ロードおよびファイル・キャッシュ・サイズを適切にチューニングします。
データベースを高速なファイル・システム上に配置します。
デプロイメントに合ったデータベース・キャッシュ・モードを使用します。
Oracle Berkeley DB Java Editionのログ・クリーナをチューニングします。
OUDがLDAPプロキシ・サーバーとして使用される場合。プロキシ・サーバーとして使用される場合、次の方法でパフォーマンスを最大にできます。
十分な数のワーカー・スレッドを用意します。パフォーマンスを最適化するには、プロキシに多くのワーカー・スレッドが必要です。
ヒープ・サイズを適切な値に設定し、正しいJVMを使用します。プロキシで4GBを超えるヒープが必要になることはほとんどないため、多くの場合、32ビットJVMを使用します。
また、特定のデプロイメント・シナリオでは、次の項目によってパフォーマンスが向上する場合があります。
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
コマンドを使用して、適切な環境変数を設定します。
OPENDS_JAVA_BIN環境変数を(JAVAのバイナリ・パスを使用して)設定します。
OPENDS_JAVA_HOME環境変数を(JAVAのインストール・パスを使用して)設定します。
ここでは、Unified Directoryのパフォーマンス情報を収集するために使用できる、主要な監視ツールの概要について説明します。
注意: Oracle Unified Directoryでは拡張可能な監視フレームワークが提供されます。Oracle Unified Directoryのパフォーマンスは、Enterprise Manager Grid Controlプラグインを使用して監視することもできます。詳細は、Oracle Unified Directory用システム監視プラグイン・ユーザーズ・ガイドを参照してください。 |
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
の値が小さい場合は、クライアント・アプリケーションに問題がある可能性が高くなります。
Oracle Unified Directory管理者ガイドの次の項には、Lightweight Directory Application Protocol (LDAP)を使用したサーバーの監視手順が詳しく記載されています。
cn=monitorエントリを使用した監視情報の表示に関する項
manage-tasksコマンドを使用した監視に関する項
JConsoleを使用したサーバーの監視に関する項
次の項では、Oracle Unified Directoryのチューニング中にも考慮する必要がある、基本的なチューニング構成について説明します。
第2章「Java仮想マシン(JVM)のチューニング」で説明したとおり、JAVA_ARGS
環境変数を使用して、JVMに渡すことができるグローバル構成引数を提供するか、java.properties
ファイルを使用できます。java
コマンドで使用できる引数はすべて、どちらの方法でも使用できます。
次の表では、Oracle Unified Directory用にチューニングできる主なJVMオプションについて説明します。これらのうち、一部の設定はSun JVMにのみ適用されますが、類似した設定がJRockitに適用される場合があります。
パラメータ | 説明 | OUDをディレクトリ・サーバーとして使用する場合 | OUDをプロキシ・サーバーとして使用する場合 |
---|---|---|---|
|
常にクライアントJVMではなくサーバーJVMを使用します。クライアントVMは、実行時間が短いプロセス用に最適化されているため、できるかぎり迅速に起動する必要があります。サーバーVMはウォームアップに時間がかかりますが、処理速度はクライアントVMよりも高速です。 |
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
次のように、32ビットまたは64ビット・バージョンのJVMを選択します。
|
使用するJVMのバージョンは、ヒープ・サイズによって異なります。 |
グローバル索引を使用する場合以外は適用されません。それ以外で、プロキシ・サーバーが4GBを超えるヒープを必要とすることはほとんどありません。 ほとんどの場合、32ビット・バージョンのJVMを使用します。 |
|
このオプションは、64ビットのJVMを使用し、ヒープ・サイズが32GB未満の場合に使用します。 |
説明に従ってこのパラメータを設定します。 |
64ビットのJVMが必要になるため、適用されません。 |
|
このパラメータによって、JVMで使用できる初期ヒープ・サイズおよび最大ヒープ・サイズが設定されます。 ヒープ・サイズを増やすとパフォーマンスが向上する場合がありますが、設定した値が大きすぎる場合、フル・ガベージ・コレクションを実行するための一時停止時間が長くなるという悪影響が生じる可能性があります。通常、初期サイズおよび最大サイズは同じ値に設定する必要があります。 パフォーマンスを最大にするには、DB全体をメモリー内にキャッシュできるようにヒープのサイズを設定します。通常は、サーバーの実行に必要なヒープを割り当て、残りをDBキャッシュに割り当てます。 CMSを古い世代のガベージ・コレクタとして使用する場合、ヒープ・サイズを計算するときに、DBキャッシュによって占有されるサイズ(またはヒープの割合)と整合がとれるよう、
|
説明に従ってこのパラメータを設定します。 例:
-Xms31G |
説明に従ってこのパラメータを設定します。 例:
|
|
ヒープ領域全体は、古い世代と若い世代に分かれます。このパラメータによって、若い世代のサイズが設定されます。残りのメモリー(古い世代)に対しては、DBキャッシュに加えて、若干のオーバーヘッドを保持できるだけのサイズを確保する必要があります。 |
説明に従ってこのパラメータを設定します。 例:
|
説明に従ってこのパラメータを設定します。 例:
|
|
並行Mark Sweep (CMS)ガベージ・コレクタを使用します。このオプションを使用すると、JVMにおけるLDAP操作のレスポンス時間を最小化できますが、サーバーの全体的なパフォーマンス(スループット)に若干の影響を与える可能性があります。一時停止時間が長くなることを許容できない場合は、このオプションを使用してください。 |
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
CMSガベージ・コレクションが開始されるレベルを指定します。デフォルト値は約68%です。デフォルト値以外の割合を設定する場合は、この値を使用してください。 CMSを古い世代のガベージ・コレクタとして使用する場合、ヒープ・サイズを計算するときに、DBキャッシュによって占有されるサイズ(またはヒープの割合)と整合がとれるよう、CMSプロパティ-
|
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
|
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
競合があまり発生しないことが予想される場合に、サーバー内で発生するロックのパフォーマンスを向上させます。 |
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
メモリー内に格納する情報に対して、サイズの大きいページを使用します。 注意: この引数は主に、UltraSPARC T1プロセッサを使用するシステムに適用されます。 |
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
注釈の一時停止時間を短縮するために、注釈の前に簡単なコレクションを実行します。 |
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
|
注意: このオプションは、UltraSPARC Txプロセッサでのみ使用する必要があります。 |
説明に従ってこのパラメータを設定します。 |
説明に従ってこのパラメータを設定します。 |
サーバーの様々なコンポーネントをチューニングして、特定のシナリオにおけるパフォーマンスを改善できます。パフォーマンスのチューニングに関する推奨事項のほとんどは、予想されるワークロード、格納されるデータのタイプ、使用可能なハードウェアとリソースなど、いくつかの可変要素に依存します。チューニングに関する次の一般的な推奨事項によって、特定のデプロイメントにおけるサーバーのパフォーマンスを改善できます。
Oracle Berkeley DB Java Editionは、埋込み可能なオープン・ソースのトランザクション・ストレージ・エンジンです。Oracle Berkeley DB Java Editionのアーキテクチャでは、非常に高いパフォーマンスが実現され、読取りの集中するワークロードと書込みの集中するワークロードを同時に実行できます。
次のBerkeley DB Java Edition (JE)チューニング・パラメータを使用して、パフォーマンスをチューニングできます。
パラメータ | 説明 |
---|---|
|
これらのプロパティを使用して、データベース・キャッシュで使用されるメモリーの量を構成します。db-cache-sizeは、ディレクトリのサイズと使用可能なメモリーの量に依存します。 キャッシュ・オプションには、次の2つがあります。
db-cache-sizeを正確に設定するには、まずインポート後にデータベースのおおよそのサイズを特定する必要があります。たとえば、
$ cd INSTANCE_DIR/OUD/db
$ du -sk userRoot/
910616 userRoot/
Windowsシステム上では、同等の手順を使用してデータベースのサイズを確認します。データベースのサイズは静的ではなく、変更が加えられたときの最初のインポート後に増加する場合があります。 JVMヒープを2GBに設定し( |
|
このプロパティを |
|
起動時にデータベースの内容をメモリー内に事前ロードするようにサーバーを構成できます。データベースのサイズが大きい場合、データベース・キャッシュを事前ロードすることによって、サーバー起動後のウォームアップ時間を短縮できます。 |
|
十分なサイズのストレージを備えた高速なファイル・システム上でデータベースを保持します。このファイル・システムとは異なる場所にアクセス・ログを配置する必要があります。デフォルトでは、データベースのサイズは元の2倍になります。たとえば、インポート後のデータベースのサイズが1GBである場合、ファイル・システムでは2GB以上が使用可能になっている必要があります。 |
|
このプロパティを使用して、データベース・キャッシュによる情報の保持方法を制御します。この値を |
|
このプロパティを使用して、書込み操作の永続性を構成します。永続性が低下すると、書込みのパフォーマンスは向上する場合がありますが、JVMやシステムのクラッシュ時にデータが失われる可能性が高くなります。このプロパティの値は、次のいずれかです。
|
|
このプロパティを使用して、JEログ・ファイルのサイズを制御します。ファイル・サイズを増やすと書込みのパフォーマンスが向上する場合がありますが、目標とする使用率の維持がより難しくなる可能性があります。 |
および |
これらのプロパティは、クリーナの動作を制御することによって、データベース・サイズの増加を抑え、書込みの高いスループットを維持します。不要になった古いレコードはクリーンアップされます。チューニングされていない場合、クリーンアップ・プロセスはパフォーマンスに影響を与える可能性があります。 |
|
多くのCPUを搭載したシステムでは、このプロパティによってデータベース・ロック・マネージャ内の同時実行性が向上する場合があります。 |
次に示すコア・サーバーのチューニング・パラメータを使用して、パフォーマンスをチューニングできます。
パラメータ | 説明 |
---|---|
|
このプロパティを構成して、LDAP接続ハンドラで(有効になっている場合はLDAPS接続ハンドラでも)クライアント・リクエストのデコードに複数のスレッドを使用できます。多くのCPUを搭載したシステムでスレッド数を増やすと、パフォーマンスが向上する場合があります。大まかに言えば、このプロパティはCPU数の4分の1(最大値は12)に設定する必要があります。
|
|
このプロパティのデフォルト値は、CPU数の2倍です。ほとんどのデプロイメントには、この値で十分です。 |
|
アクセス・ログのパブリッシャを高速ファイル・システム上に配置するか、 |
次に示す追加の推奨事項によって、特定のシナリオにおけるパフォーマンスが向上する場合があります。
エントリ・キャッシュの有効化。エントリ・キャッシュの有効化は、特にディレクトリのサイズが比較的小さい場合(たとえば、数十万エントリまで)に役立ちます。通常は、ソフト参照のエントリ・キャッシュよりもFIFOのエントリ・キャッシュの方が優れた結果を提供します。
大規模なデータベースの場合は、include-filter
プロパティを使用して、特定のデータ・セットのみをキャッシュ内に格納することをお薦めします。静的グループをエントリ・キャッシュ内に格納すると、サーバーの全体的なパフォーマンスが大幅に向上する可能性があります。これにより、ACIの評価などで必要になるグループ・メンバーシップ参照の実行時間が短縮されます。
使用されていない仮想属性の無効化。1つ以上の仮想属性によって使用される機能が不要な場合、それらを無効にすると、エントリのデコード時のパフォーマンスが若干向上する可能性があります。
使用されていないアクセス・ロギングの無効化。アクセス・ロギングが不要な場合、サーバーのアクセス・ロガーを無効にすると、パフォーマンスが向上する可能性があります。
使用されていないアクセス制御ハンドラの無効化。サーバー内のアクセス制御処理が不要な場合は、アクセス制御ハンドラのenabled
構成プロパティをfalse
に設定することによって、ハンドラを無効にできます。このプロパティはdsconfig
を使用して設定できます。
ロック競合の削減。多くのCPUが搭載されたシステム(たとえば、コアごとにいくつかのハードウェア・スレッドを提供するチップマルチスレッド化(CMT)システム)では、org.opends.server.LockManagerConcurrencyLevel
システム・プロパティを、使用するワーカー・スレッドと同じ数に設定することによって、ロック競合を削減できます。
注意: このプロパティは、サーバー起動プロセスの非常に早い段階(サーバー構成へのアクセスよりも前)で必要になるため、JVMシステム・プロパティとして設定する必要があります。