| Oracle® Fusion Middleware Oracle Unified Directory管理者ガイド 11g リリース2 (11.1.2) B72794-04 |
|
 前 |
 次 |
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エントリにあります。詳細は、第32章「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のインストール・パスを使用して)設定します。
dsjavapropertiesユーティリティを使用したJava仮想マシン設定のチューニングJAVA_ARGS環境変数を使用して、JVMに渡すことができるグローバル構成引数を提供するか、java.propertiesファイルを使用できます。javaコマンドで使用できる引数はすべて、どちらの方法でも使用できます。
最適なパフォーマンスを実現するためにJVMをチューニングして、Oracle Unified Directoryアプリケーションを強固かつ応答を早くすることをお薦めします。ヒープ・サイズをチューニングすることによってJVMをチューニングできます。ヒープ・サイズは、次のように分割されます:
若い世代: PDUやローカル変数などの操作を含みます。
古い世代: JEデータベース・キャッシュやエントリ・キャッシュなどのOracle Unified Directoryキャッシュを含みます。
永続世代: 定数およびクラスを含みます。
Oracle Unified Directoryがディレクトリ・サーバー・モードの場合、次のデータベース・キャッシュ・オプションのいずれかを実行できます:
データベース・キャッシュのデータベース全体をキャッシュします。これによって最適なパフォーマンスが与えられますが、キャッシュ・ウォームアップが長くなり、ヒープ・サイズが大きくなります。
データベース・キャッシュでデータベースのBツリー(上位ノードおよび内部ノード)の内部ノードのみをキャッシュし、残りのRAMをファイル・システム・キャッシュ用に保持します。これによってパフォーマンスが向上し、ウォームアップが短くなり、ヒープ・サイズが小さくなります。非常に大きいデプロイ(50MBytesエントリ超)用にお薦めします。小規模および中規模のデプロイにお薦めします。
詳細は、第33.5項「データベース・キャッシュ・サイズの決定」を参照してください。
|
注意: プロキシ・モードでは、グローバル索引を使用した配布に大きい古い世代を使用します。 |
詳細は、「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プロセッサを使用するシステムなど)ではこれが不適切である可能性があります。 |
dstuneユーティリティを使用したJava仮想マシン設定のチューニングdstuneコマンド行ユーティリティでは、自動モードを使用して、またはメモリー制限を指定するなどの条件を使用して、サーバーをチューニングできます。dstuneユーティリティを使用して実行された変更は、サーバーの再起動時に反映されます。
dstuneコマンド行ユーティリティは、Oracle Unified Directoryサーバーやその他のチューニング対応ツールで使用されるJVM引数をチューニングします。
この項では、dstuneコマンド行ユーティリティで提供される様々なオプションを使用して、Oracle Unified Directoryをチューニングする方法を説明します。この項の内容は次のとおりです。
|
注意: 第33.4.1.1「 |
dstuneユーティリティの使用この項では、dstuneユーティリティを使用した様々なチューニング・オプションについて説明します。項目は次のとおりです。
dstuneユーティリティで提供されるチューニング・オプションdstuneユーティリティでは、次のチューニング・オプションに基づいてサーバーをチューニングできます。
自動モードでは、マシンで使用可能なリソースとその構成に基づいて、サーバーを自動的にチューニングできます。サーバーのチューニングは、サーバーの起動のたびに実行されます。これは、デフォルトのモードで、チューニングのために追加の情報を指定する必要はありません。
自動チューニング・オプションの使用の詳細は、付録A「dstune」を参照してください。
データベース・モードでは、ディレクトリのデータについての説明情報を基にサーバーをチューニングできます。サーバーに含まれるデータについての情報を指定する必要があります。データには、次のように異なる種類のものを指定できます。
LDIFファイル内のデータ。
データの正確な数値(エントリの数とエントリの平均サイズ)。
データベース・チューニング・オプションの使用の詳細は、付録A「dstune」を参照してください。
メモリーベース・モードでは、サーバーが使用するヒープ・サイズに基づいて、サーバーをチューニングできます。
メモリーベース・オプションによって、使用すべきJavaヒープ・サイズに基づいてツールをチューニングできます。ヒープ・サイズを指定するには--memoryを指定し、値を適用する必要があるツールを指定するには--targetToolを使用します。サーバーJVM設定は適宜チューニングされます。
メモリーベース・チューニング・オプションの使用の詳細は、付録A「dstune」を参照してください。
実行時モードでは、直接JVM引数を指定してサーバーをチューニングできます。また、実行時チューニング・オプションを使用してサーバー実行時のメモリー制限を指定したり、--targetTool引数を使用して指定できるその他ツールを使用できます。サーバーJVM設定は適宜チューニングされます。
このモードの特徴は、チューニング対応ツールごとに個別に自動モードを有効化できることです。
実行時チューニング・オプションの使用の詳細は、付録A「dstune」を参照してください。
dstuneユーティリティを使用して、Oracle Unified Directoryサーバーとチューニング対応ツールの現在のチューニング設定を表示できます。
次のコマンドは、Oracle Directory Serverインスタンスの現在のチューニング設定を表示します。
$ dstune list Tool : Tuning Value --------------:------------------ server : -server import-ldif : -Xmx2048m -server export-ldif : Automatic Tuning rebuild-index : Automatic Tuning verify-index : -Xmx2048m -server
dstuneユーティリティの対話モードの例この項では、dstuneユーティリティの対話モードを使用して、Oracle Unified Directoryをチューニングする方法を説明します。この項の内容は次のとおりです。
この項では、対話モードでdstuneユーティリティのメモリー制約を使用して、Oracle Unified Directoryサーバーをチューニングする方法の例を示します。
この例では、最大ヒープ・サイズの1583 MBを使用するためにサーバーJVMを構成します。JVM設定はメモリー制約に従ってチューニングされます。
dstuneコマンドを次のように実行します:
bin/dstune
What do you want to do?
1) Enable Automatic Tuning
2) Tune Based on Memory Limits
3) Tune Based on LDAP Data Information
4) Tune Providing Runtime Options
5) List the Current Tuning Settings
c) cancel
Enter choice [Enable Automatic Tuning]: 2
You must provide the heap size to be used by the tools.
To specify a value in megabytes, use 'm' after the value (for instance 768m).
For gigabytes, use 'g' (for instance 2.5g).
If no unit is specified after the value, megabytes will be used.
Heap Size [1583m]:
You must provide the tools the runtime options will apply to.
If you want to use the settings for the server, provide the value 'server'.
If you want to use the settings for all the tools, provide the value 'all'.
The other allowed values are import-ldif, export-ldif, rebuild-index, verify-index.
You can provide several values separated with a comma (for instance 'export-ldif,rebuild-index').
Tools [server]: server
Calculating Tuning Settings ..... Done.
Updating the tuning properties ..... Done.
Updating scripts ..... Done.
この項では、対話モードでdstuneユーティリティのデータベース・チューニング・オプションを使用して、Oracle Unified Directoryサーバーをチューニングする方法の例を示します。
この例では、提供されたLDIFファイルのコンテンツに従ってサーバーを構成します。
dstuneコマンドを次のように実行します:
bin/dstune
What do you want to do?
1) Enable Automatic Tuning
2) Tune Based on Memory Limits
3) Tune Based on LDAP Data Information
4) Tune Providing Runtime Options
5) List the Current Tuning Settings
c) cancel
Enter choice [Enable Automatic Tuning]: 3
Provide information about the LDAP data that the server will contain. This information will be used to tune the server. You can provide an LDIF File with the data, or directlry the number and average size of your entries.
1) Use the contents of an LDIF file
2) Use the number of entries
c) cancel
Enter choice [Use the contents of an LDIF file]:
LDIF File Path: /tmp/myldif.ldif
Calculating Tuning Settings ..... Done.
Updating the tuning properties ..... Done.
Updating scripts ..... Done.
この項では、対話モードでdstuneユーティリティの実行時チューニング・オプションを使用して、Oracle Unified Directoryサーバーをチューニングする方法の例を示します。
この例では、JVM引数の-server -Xmx2048mを使用するためにimport-ldifおよびverify-indexツールを構成します。
dstuneコマンドを次のように実行します:
bin/dstune
What do you want to do?
1) Enable Automatic Tuning
2) Tune Based on Memory Limits
3) Tune Based on LDAP Data Information
4) Tune Providing Runtime Options
5) List the Current Tuning Settings
c) cancel
Enter choice [Enable Automatic Tuning]: 4
You must provide the runtime options you want to use.
If you want to use automatic tune, provide the value 'autotune'.
If you want to use the default settings of the Java Virtual Machine on your system, provide the value 'jvm-default'.
You can also provide directly the Java arguments that the tools must use.
Runtime Options [autotune]: -server -Xmx2048m
You must provide the tools the runtime options will apply to.
If you want to use the settings for the server, provide the value 'server'.
If you want to use the settings for all the tools, provide the value 'all'.
The other allowed values are import-ldif, export-ldif, rebuild-index, verify-index.
You can provide several values separated with a comma.
Tools [server]: import-ldif,verify-index
Calculating Tuning Settings ..... Done.
Updating the tuning properties ..... Done.
Updating scripts ..... Done.
この項では、dstuneユーティリティの対話モードを使用して、Oracle Unified Directoryサーバー・インスタンスの現在のチューニング・モードを表示する方法を説明します。
dstuneコマンドを次のように実行します:
bin/dstune
What do you want to do?
1) Enable Automatic Tuning
2) Tune Based on Memory Limits
3) Tune Based on LDAP Data Information
4) Tune Providing Runtime Options
5) List the Current Tuning Settings
c) cancel
Enter choice [Enable Automatic Tuning]: 5
Tool : Tuning Value
--------------:------------------
server : -server
import-ldif : -Xmx2048m -server
export-ldif : Automatic Tuning
rebuild-index : Automatic Tuning
verify-index : -Xmx2048m -server
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システム・プロパティとして設定する必要があります。 |
