Oracle® Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース2(11.1.2.1.0) B71702-02 |
|
前 |
次 |
この章では、インストールされているOracle Internet Directoryのチューニングおよびサイズ設定のガイドラインを示します。内容は次のとおりです。
Oracle Internet Directoryは、オラクル社のLightweight Directory Application Protocol(LDAP)バージョン3のディレクトリ・サーバーです。Oracle Internet Directoryは、スケーラビリティ、可用性および管理性に優れています。また、マルチスレッド、マルチプロセス、マルチインスタンスのプロセス・アーキテクチャを備え、Oracle Databaseをディレクトリ・ストアとして使用します。この独自の物理アーキテクチャにより、Oracle Internet Directoryは、対称型マルチプロセッサ(SMP)、不均一メモリー・アクセス(NUMA)、クラスタ・ハードウェアなどの複数のハードウェア・アーキテクチャにデプロイできます。Oracle Internet Directoryの物理アーキテクチャは、ハードウェア・リソースおよび多数の高可用性構成で、リニアなパフォーマンスのスケーラビリティを実現します。
詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』を参照してください。
注意: Oracle Internet Directoryのデフォルト構成は、ほとんどの本番用デプロイメントおよびテスト用デプロイメントにとって最適なものではありません。最適なパフォーマンスおよび可用性を得るには、少なくとも23.3項「チューニングに関する基本的な考慮事項」に示す手順に従う必要があります。 |
関連項目:
|
この章の推奨事項の多くは、Oracle Internet Directoryのシステム構成属性およびレプリケーション構成属性の変更を必要とします。
関連項目:
Oracle Internet Directoryの構成属性の詳細は、これらを参照してください。 |
Oracle Internet Directoryデータベースのリアルタイム・パフォーマンス・メトリックを監視すると、パフォーマンス・ボトルネックを特定できます。他のOracle Fusion Middlewareコンポーネントの監視方法の詳細は、第4章「Oracle Fusion Middlewareの監視」を参照してください。
Linux、Solaris、その他のUNIXライクなオペレーティング・システムを使用している場合は、次の各ツールを理解しておくことをお薦めします。
ツール | 説明 |
---|---|
システムでCPUを最も多く消費しているタスクを表示します。 |
|
Virtual Memory Managerなど、システムの様々な部分の実行統計を示します。 |
|
vmstatと同様の出力ですが、システム内の各種CPUにわたって分割して示します。これはSolarisでのみ使用可能です。 |
|
各種ディスク・コントローラからのディスクI/O統計を示します。 |
|
システムのアクティビティ情報を収集、報告または保存します。 |
Microsoft Windowsを使用している場合は、次のツールを理解しておくことをお薦めします。
ツール | 説明 |
---|---|
システム内のイベントのカスタマイズされたビューを表示します。 |
|
システムで実行されている主なタスクの大まかな出力(UNIXの |
Oracle Databaseを使用する場合は、次のツールを理解しておくことをお薦めします。
DBMS_STATSパッケージのANALYZEファンクション
関連項目:
|
オペレーティング・システム・ツール以外に、カスタマ環境で使用されているLDAPアプリケーションも待機時間やスループットの測定方法を提供しています。
さらに、様々なデータベースodsスキーマ・オブジェクトを分析して統計を見積るために、$
ORACLE_HOME
/ldap/admin
にあるデータベース統計収集ツール(oidstats.sql)が提供されています。第23.2.3項「oidstats.sqlを使用したデータベース統計の更新」を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlには、Oracle Internet Directoryのチューニングおよびサイズ設定に便利なツールが用意されています。
このウィザードを使用して、システムのチューニングおよびサイズ設定に関する推奨事項を取得します。「チューニング」、「サイズ設定」または「両方」を選択できます。「サイズ設定」または「両方」を選択した場合は、「基本」または「拡張」を選択できます。
チューニング
「Oracle Internet Directory」メニューから、「管理」→「チューニングとサイズ設定」を選択します。
「作成」アイコンをクリックしてウィザードを起動します。
「タイプ選択」ページで、レポート名を変更し、「チューニング」を選択します。
ウィザードに「ハードウェア」、「機能」、「ロード」、「データ特性」および「ガベージ・コレクション」の各ページが表示されます。
各ページで、テキスト・フィールドに値を指定(またはデフォルト値を使用)し、質問ごとに「はい」または「いいえ」を選択します。一部の選択肢は、前の選択内容に応じてグレー・アウトされている場合があります。ほとんどのフィールドには、カーソルをフィールド上に移動すると表示されるツールチップが用意されています。
次のページに進むには「次へ」、前のページに戻るには「戻る」をクリックします。ウィザードを閉じるには、「取消」をクリックします。
「確認」ページで、入力したデータを確認します。指定内容を変更するには「戻る」、レポートを表示するには「終了」をクリックします。
レポートは、ページの右下のセクションに表示されます。
レポートをダウンロードするには、「レポートのダウンロード」をクリックします。レポートを削除するには、「削除」をクリックします。
サイズ設定
「Oracle Internet Directory」メニューから、レポート名を変更し、「管理」→「チューニングとサイズ設定」を選択します。
「作成」アイコンをクリックしてウィザードを起動します。
「タイプ選択」ページで、「サイズ設定」を選択します。
「基本」または「拡張」を選択します。
「サイズ設定」ページで、テキスト・フィールドに値を指定(またはデフォルト値を使用)し、質問ごとに「はい」または「いいえ」を選択します。一部の選択肢は、前の選択内容に応じてグレー・アウトされている場合があります。
「次へ」をクリックします。
「確認」ページで、入力したデータを確認します。指定内容を変更するには「戻る」、レポートを表示するには「終了」をクリックします。
レポートは、ページの右下のセクションに表示されます。
レポートをダウンロードするには、「レポートのダウンロード」をクリックします。レポートを削除するには、「削除」をクリックします。
両方
「Oracle Internet Directory」メニューから、レポート名を変更し、「管理」→「チューニングとサイズ設定」を選択します。
「作成」アイコンをクリックしてウィザードを起動します。
「タイプ選択」ページで、「両方」を選択します。
「基本」または「拡張」を選択します。
「次へ」をクリックします。
ウィザードに「サイズ設定」、「ハードウェア」、「機能」、「ロード」、「データ特性」および「ガベージ・コレクション」の各ページが表示されます。
各ページで、テキスト・フィールドに値を指定(またはデフォルト値を使用)し、質問ごとに「はい」または「いいえ」を選択します。一部の選択肢は、前の選択内容に応じてグレー・アウトされている場合があります。
次のページに進むには「次へ」、前のページに戻るには「戻る」をクリックします。ウィザードを閉じるには、「取消」をクリックします。
「確認」ページで、入力したデータを確認します。指定内容を変更するには「戻る」、レポートを表示するには「終了」をクリックします。
レポートは、ページの右下のセクションに表示されます。
レポートをダウンロードするには、「レポートのダウンロード」をクリックします。レポートを削除するには、「削除」をクリックします。
データベース統計が自動的に更新され、OIDMONがデータベースの構成された数の更新ごとにoidstats.sql
を実行します。デフォルトでは、5000エントリが追加されるたびに、OIDMONがoidstats.sql
を実行します。次のようにldapmodify
コマンドを使用して、この頻度を変更できます。
$ORACLE_HOME/bin/ldapmodify -p <oidPort> -h <oidHost> -D cn=orcladmin -w <adminPassword> << eof dn: cn=configset,cn=oidmon,cn=subconfigsubentry changetype: modify replace: orclstatsperiodicity orclstatsperiodicity: <desired_number> eof
関連項目: 『Oracle Fusion Middleware Oracle Identity Managementリファレンス』の |
レプリケーション属性を設定するには、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードまたはコマンドラインを使用します。
属性orclthreadspersupplier
、orclchangeretrycount
およびorclconflresolution
は、レプリケーション構成セット属性です。
関連項目:
次の情報については |
属性orclhiqschedule
およびorclupdateschedule
は、レプリケーション承諾エントリ属性です。
関連項目:
|
関連項目:
|
ほとんどのパフォーマンス関連のシステム構成属性は、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンドラインから設定できます。Oracle Directory Services Managerのデータ・ブラウザを使用してシステム構成属性を変更することもできます。
Oracle Internet Directoryのシステム構成属性の設定の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「システム構成属性の管理」を参照してください。
「Fusion Middleware Controlを使用したシステム構成属性の管理」
「WLSTを使用したシステム構成属性の管理」
「LDAPツールを使用したシステム構成属性の管理」
「ODSMデータ・ブラウザを使用したシステム構成属性の管理」
属性orclpurgetargetage
およびorclpurgeinterval
は、変更ログ・パージ構成エントリにあります。これらは、ldapmodify
またはOracle Directory Services Managerを使用して変更できます。
次の例は、変更ログのパージの構成に使用するLDIFファイルです。
関連項目: 変更ログのパージの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の変更ログのパージに関する項を参照してください。 |
この例では、120時間(5日)の時間ベースのパージを構成しています。次のようなLDIFファイルを使用します。
dn: cn=changelog purgeconfig,cn=purgeconfig,cn=subconfigsubentry changetype:modify replace: orclpurgetargetage orclpurgetargetage: 240
LDIFファイルmod.ldif
を適用するには、次のように入力します。
ldapmodify -D "cn=orcladmin" -q -p port -h host -D dn -q -f mod.ldif
関連項目: 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の時間ベースの変更ログのパージの構成に関する項。 |
orclpurgetargetage
およびorclpurgeinterval
は、Oracle Directory Services Managerのデータ・ブラウザを使用して変更できます。データ・ツリーで変更ログ・パージ構成エントリに直接移動することはできませんが、次のように拡張検索を使用すると可能です。
「データ・ブラウザ」タブで「拡張」をクリックします。
左ペインで「ガベージ・コレクション」を展開し、「changelog purgeconfig」を選択します。ガベージ・コレクタ・ウィンドウが右ペインに表示されます。
右ペインで、パージのターゲット期間およびパージの間隔に加える変更を入力します。
「適用」を選択します。
チューニングとは、ディレクトリのパフォーマンスを改善するためにパラメータを調整することです。Oracle Internet Directoryのデフォルト構成は、ほとんどすべてのデプロイメントでチューニングを必要とします。この項に記載されている要件および推奨事項を十分に確認してください。
Oracle Databaseインスタンス・パラメータの推奨される最小値を表23-1に示します。
表23-1 Oracle Databaseインスタンス・パラメータの最小値
Oracle Databaseインスタンス・パラメータの設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。
この項の推奨事項は、表23-2にまとめてあります。
LDAPアプリケーション・トラフィックを処理するOracle Internet Directoryサーバー・インスタンスのプロセスおよびスレッドの数をチューニングします。これは、全体的なパフォーマンスに大きな影響を与えます。表23-2に記載されたorclmaxcc
およびorclserverprocs
の推奨設定を参照してください。
レプリケーションまたはOracle Directory Integration Platformをデプロイしない場合、変更ログの生成を無効にします。属性orclgeneratechangelog
を0
に設定します。
ディレクトリに参照エントリがない場合、LDAP検索で参照をスキップします。orclskiprefinsql
を1に設定します。これは、パフォーマンスに大きな影響を与える可能性があります。
アイドル状態のLDAP接続をオープンのままにせず、一定時間の経過後にクローズします。こうすると、接続が必要以上に増えるのを防止できます。たとえば、orclldapconntimeout
を60分に設定します。
これは、g(10.1.4.0.1)から、操作統計を追跡するよう構成されていないユーザーにしか設定できなくなりました。統計を収集するよう構成されているユーザーの接続は、この設定に従ってタイムアウトしません。
関連項目: 『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のFusion Middleware Controlを使用した統計収集のためのユーザーの構成に関する項。 |
LDAP検索操作のベースDNがディレクトリになく、クライアントが詳細なMatchDN情報を必要としない場合は、詳細なMatchDN情報を無効にします。orclmatchdnenabled
を0に変更します。
表23-2 チューニングするLDAPサーバー属性
属性 | デフォルト | 推奨値 | 注意 |
---|---|---|---|
2 |
10 |
サーバーの再起動が必要です。 |
|
1 |
システムのCPUコアの数 |
||
0 |
1 |
この変更を行うことを強くお薦めします。LDAP参照エントリがある場合は変更しないでください。LDAP参照エントリは共通ではありません。 サーバーの再起動が必要です。 |
|
1 |
0 |
レプリケーションまたはOracle Directory Integration Platformをデプロイしない場合にのみ、変更ログの生成を無効にします。 |
|
0(タイムアウトなし) |
場合によって異なる(一般的には60分) |
統計を追跡するよう構成されているユーザーはタイムアウトしません。 |
|
1 |
0 |
検索のベースDNが存在せず、アプリケーションが詳細なMatchDN情報を必要としない場合にのみ、無効にします。 |
Oracle Enterprise Manager Fusion Middleware Controlを使用したorclserverprocs
、orclldapconntimeout
およびorclmatchdnenabled
の構成の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項を参照してください。
Oracle Enterprise Manager Fusion Middleware Controlを使用したorclskiprefinsql
またはorclmatchdnenabled
の構成の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の共有プロパティの構成に関する項を参照してください。
これらの属性およびorclgeneratechangelog
のコマンドラインからの構成の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
LDAPコマンドを使用して多数のエントリをOracle Internet Directoryに追加すると、ディレクトリのパフォーマンスに影響が出ることがあります。その場合は、データベース統計を更新します。第23.2.3項「oidstats.sqlを使用したデータベース統計の更新」を参照してください。
通常、この操作が必要になるのは、Oracle Internet Directoryのインストール後に初めてエントリをバルクで追加する場合のみです。データベース統計は夜間に自動的に更新されるため、この操作を再度実行する必要はありません。ただし、データ・フットプリントを変更していないのにLDAP操作が突然遅くなった場合は、一度oidstats.sql
を実行してパフォーマンスが改善するかどうか確認することを検討してください。データベースSQL実行計画の変更が原因で影響が出ている可能性があります。この場合は、oidstats.sqlによって改善します。
関連項目: SQLチューニングの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。 |
bulkload
ツールを使用してエントリを追加する場合、データベース統計の更新は不要です。データベース統計は、bulkload
コマンドによって自動的に更新されます。
この項では、パフォーマンスを改善することはあるが、優先度が低いとみなされている属性について説明します。
属性orclsizelimit
は、検索で返されるエントリの最大数を制御します。デフォルト値は10000です。この値を非常に大きくすると、サーバーのパフォーマンスに影響が出ます。また、レプリケーション・サーバーが一度に処理できる変更ログの最大数を制限する役割も果します。
『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
インスタンス固有のサブエントリ属性orclenablegroupcache
は、権限グループおよびACLグループをキャッシュするかどうかを制御します。このキャッシュを使用すると、ユーザーのアクセス制御評価のパフォーマンスが向上します。
グループ・キャッシュは、権限グループ・メンバーシップが頻繁に変更されない場合に使用してください。権限グループ・メンバーシップが頻繁に変更される場合は、グループ・キャッシュをオフにすることをお薦めします。これは、グループ・キャッシュを計算する処理がパフォーマンスに影響を与えるためです。デフォルトは1(有効)です。0(ゼロ)に変更すると、無効になります。
『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
前の項で推奨されている変更を行った後、デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。
Oracle Internet DirectoryをOracle Directory Integration Platformまたはレプリケーションとともにデプロイする際には、この2つのサーバー専用のLDAPサーバー・インスタンスを使用すると、パフォーマンスが向上します。この場合、デフォルトのOracle Internet Directory LDAPインスタンスでLDAPアプリケーションのトラフィックを処理し、2番目のインスタンスでレプリケーション・サーバーおよびOracle Directory Integration PlatformサーバーからのLDAPリクエストを処理することができます。
『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryインスタンスの管理」の説明に従って、追加のサーバー・インスタンスを作成します。
新しいインスタンス構成で、orclmaxcc
を10に、orclserverprocs
を1に設定します。
『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の「Oracle Internet Directoryインスタンスの管理」の説明に従って、サーバーを再起動します。
新しいインスタンスが使用するSSLポートおよび非SSLポートを設定し、レプリケーションおよびOracle Directory Integration Platformがこれらのポートを指し示すように構成します。
orclmaxcc
およびorclserverprocs
を構成するには、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
注意: Oracle Internet Directoryクラスタ構成(ラックマウントまたはマルチボックス)では、レプリケーション・サーバーを1つのハードウェア・ノードでのみ起動する必要があります。レプリケーション専用のLDAPサーバー・インスタンスは、それと同じノードで起動してください。Oracle Directory Integration Platformサーバーは、別のノードにあってもかまいません。 |
次の推奨事項は、レプリケーション・トラフィックが多い場合に役立ちます。変更を行う前に、必ずトレードオフを理解しておいてください。推奨値は、表23-3にまとめてあります。
読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解決をオフにすると、パフォーマンスへの影響を軽減できます。そのためには、orclconflresolution
の値を0に変更します。
サプライヤがボトルネックになっている場合、サプライヤのorclthreadspersupplier
を増やします。コンシューマがボトルネックになっている場合も、コンシューマのorclthreadspersupplier
を増やせますが、並列度が高まることによって変更ログの適用時に競合状態が生じ、結果的に管理者操作キュー(HIQ)の変更が増加することに注意してください。
orclchangeretrycount
を減らして、新しい変更ログのリソースを増やします。ただし、競合が発生している場合は、これによって管理者操作キュー(HIQ)の変更が増加します。
orclupdateschedule
を0に変更して、サーバー・プロセスの変更ログが60秒おき(デフォルト)ではなく、ただちに作成されるようにします。これは、サプライヤとコンシューマの両方で行います。
orclhiqschedule
の値を大きくします。たとえば、管理者操作キュー(HIQ)に1日4回アクセスすれば十分であり、デプロイメントにもそれが適している場合は、orclhiqschedule
を21600秒(6時間)に設定します。
表23-3は、これらの推奨事項をまとめたものです。
表23-3 レプリケーション属性
属性 | デフォルト | 推奨値 | 注意 |
---|---|---|---|
転送=1 適用=5 |
転送スレッドを1に、適用スレッドを10以上に設定 |
サプライヤがボトルネックになっている場合に最も有効です。 |
|
10 |
4 |
変更ログのリソースが増えますが、HIQが増加することがあります。 |
|
60秒 |
0 |
変更ログがただちに処理されます。 |
|
600秒 |
21600秒 |
新しい変更を処理するためのリソースが増えます。 |
|
1 |
0 |
読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合にのみ変更します。 |
これらのレプリケーション属性の設定の詳細は、第23.2.4項「パフォーマンス関連のレプリケーション構成属性の設定」を参照してください。
デフォルトでは、Oracle Internet Directoryはデータベース・ジョブを実行して、変更ログ、サーバー管理性統計、その他のデータをパージします。各ジョブは、午前0時から15分間隔で開始されます。表23-4に示すパラメータを変更すれば、この構成をデプロイメント要件に合せて変更できます。
これらの属性は、ldapmodify
またはOracle Directory Services Managerを使用して変更できます。第23.2.6項「ガベージ・コレクション構成属性の設定」を参照してください。
第23.4.2項「レプリケーション・サーバー構成」で説明したとおり、デフォルトのサーバーに加えて、Oracle Directory Integration Platformおよびレプリケーション専用のLDAPサーバーを使用できます。Oracle Internet Directoryクラスタでは、すべてのOracle Internet DirectoryノードでデフォルトのLDAPインスタンスを起動しますが、この専用のインスタンスはOracle Directory Integration Platformおよびレプリケーションが稼働しているノードでのみ起動します。
どのデータベース・インスタンスにOracle Internet Directoryを接続するかを慎重に検討してください。
クラスタ内のOracle Databaseインスタンス間のロード・バランシング、またはフェイルオーバー・モード用にOracle Internet Directoryを構成できます。
レプリケーションおよびOracle Directory Integration Platform専用のLDAPサーバー・インスタンスを使用する場合は、そのインスタンスの接続文字列をフェイルオーバー用に構成できます。tnsnames.ora
で次の文字列を使用します。
(FAILOVER=ON)(LOAD_BALANCE=OFF)
bulkload
などのバルク操作の実行時には、ツールを1つのOracle Databaseインスタンスにのみ接続してすべての操作を実行します。
Oracle Internet Directoryインスタンスを次のように構成します。
LDAPアプリケーション・トラフィックを処理する各ノードにOracle Internet Directoryインスタンスを1つ配置
Oracle Internet Directoryレプリケーション・サーバーおよびOracle Directory Integration Platformサーバーのインスタンスを1つのノードに配置
Oracle Internet Directoryでは、パスワード・ポリシーおよびパスワード検証プロファイルがデフォルトで有効になっています。特定のデプロイメントでパスワード・ポリシーを適用する必要がない場合は、パスワード・ポリシーを無効にできます。デフォルトで有効になっているパスワード検証プロファイルは、Enterprise User SecurityやOracle Collaboration SuiteなどのOracle製品で必要とされる特定のパスワード・ベリファイアの生成を制御します。他のOracle製品用にOracle Internet Directoryがデプロイされていない場合は、すべてのパスワード検証プロファイルを無効にできます。
パスワード・ポリシーおよびパスワード・ベリファイアは、Oracle Directory Services Managerまたはldapmodify
を使用して無効にできます。
関連項目:
|
Oracle Internet Directoryのサーバー・エントリ・キャッシュを使用すると、Oracle Internet Directoryのサーバー・プロセス・ヒープにLDAPエントリをキャッシュすることで、パフォーマンスを改善できます。エントリ・キャッシュの構成によって効果が得られるのは、すべてまたは大部分のエントリがキャッシュ可能な場合のみです。
注意: サーバー・エントリ・キャッシュは、小規模なディレクトリ・デプロイメントでのみ効果的です。ここに記載したチューニング推奨事項の中には、これまでの項のチューニング推奨事項と矛盾するものもあります。特定のデプロイメントにエントリ・キャッシュを適用できるかどうかを確認し、次にあげる考慮事項のすべてが該当する場合にのみ、この項で説明するチューニングを採用してください。 |
エントリ・キャッシュを使用する主な利点の1つに、ベース・スコープを使用したLDAP検索操作が約5倍速くなることがあります。これは、エントリのすべて、または大半がキャッシュ可能な場合にのみ当てはまります。キャッシュ・ミスは、エントリ・キャッシュを無効にするよりコストがかかります。
サーバー・エントリ・キャッシュは、表23-5に示す値を設定することで構成および最適化できます。
表23-5 サーバー・エントリ・キャッシュの構成
属性 | デフォルト | 推奨値 | 注意 |
---|---|---|---|
2 |
10 |
この属性を変更した後、サーバーを再起動します。 |
|
1 |
システムのコアの総数。 |
||
1 |
1 |
||
200000000バイト |
ディレクトリの合計サイズ(バイト) |
この属性の最適な設定を決定するには、ディレクトリ情報ツリーのエントリ数を使用し、その数に平均エントリ・サイズを掛けます。 LDIF形式のエントリ・サイズの3倍の見積りをしてください。 |
|
100000 |
DIT内のエントリ総数 |
||
1000000 |
DIT内の最大エントリのサイズ(バイト) |
通常、最大エントリはグループ・エントリまたはバイナリ属性値のエントリです。 |
たとえば、ディレクトリ情報ツリーの合計サイズが300Kで、LDAPデータ交換ファイル(LDIF)形式の300Kのエントリの合計サイズが500Mである場合、orclecacheenabled
を1に、orclecachemaxsize
を1,500,000,000に、orclecachemaxentries
を300,000に設定します。最大のグループ・エントリまたはバイナリ値のエントリのサイズが10Mの場合、orclecachemaxentsize
を10,000,000に設定します。
ディレクトリ情報ツリーのエントリ数を取得するには、次のコマンドを使用します。
sqlplus ods@oiddb select count(*) from ct_dn; oidctl connect=oiddb status -diag
次の例は、oidctl connect=oiddb status -diag
コマンドの出力を示しています。
+--------------------------------------------------------------------------+ | Process | PID | InstName | CompName |Inst#| Port | Sport | +--------------------------------------------------------------------------+ | oidmon | 8192 | inst1 | oid1 | 0| | | +--------------------------------------------------------------------------+ | oidldapd disp| 8201 | inst1 | oid1 | 1| 5678 | 0 | | oidldapd serv| 8205 | inst1 | oid1 | 1| 5678 | 0 | | oidldapd serv| 8209 | inst1 | oid1 | 1| 5678 | 0 | | oidldapd serv| 8213 | inst1 | oid1 | 1| 5678 | 0 | | oidldapd serv| 8217 | inst1 | oid1 | 1| 5678 | 0 | | Config DN | cn=oid1,cn=osdldapd,cn=subconfigsubentry | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ |Printing LDAP Operation in progress status ... | +--------------------------------------------------------------------------+ +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8205 WorkerID: 8 DBSID: 168 DBPID: 8245 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8205 WorkerID: 9 DBSID: 170 DBPID: 8253 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8205 WorkerID: 10 DBSID: 180 DBPID: 8261 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8205 WorkerID: 11 DBSID: 189 DBPID: 8269 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8209 WorkerID: 13 DBSID: 171 DBPID: 8249 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8209 WorkerID: 9 DBSID: 181 DBPID: 8257 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8209 WorkerID: 12 DBSID: 193 DBPID: 8267 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8209 WorkerID: 10 DBSID: 199 DBPID: 8225 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8209 WorkerID: 11 DBSID: 190 DBPID: 8227 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8205 WorkerID: 13 DBSID: 197 DBPID: 8223 ==> IDLE +--------------------------------------------------------------------------+ OIDLDAPD_PID: 8205 WorkerID: 12 DBSID: 182 DBPID: 8229 ==> IDLE +--------------------------------------------------------------------------+ Cache Max Size : 1000000512 Max Entries configured : 1000000 Max Entries cached : 100000 Num Entries in Cache : 100000 Num Entries in GC : 0 Page size : 976556 Entry cache Hit count : 6172127 Entry cache Mis count : 99999 Hash Area bytes used : 24497696 Hash Area blocks used : 37 ResultSet cache bytes used : 6799604 Resultset cache blocks used : 300000 Entry cache bytes used : 404047820 Entry cache blocks used : 5900293 Cache memory used : 435345120
属性を構成するには、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
結果セット・キャッシュは、完全な結果セットをメモリーに格納できるようにするOracle 11g OIDの機能です。SQL問合せが実行され、その結果セットがキャッシュ内にある場合、SQL実行のオーバーヘッドのほぼ全部が回避されます。これには、解析時間、論理読取り、物理読取り、通常に発生するキャッシュ競合オーバーヘッド(インスタンスのラッチ)が含まれます。結果キャッシュを構成すると、パフォーマンスが向上する可能性があります。これは、ほとんどのLDAPアプリケーションは通常、mail=john.doe@acme.comやuid=john.doeなどのユーザー・エントリをユーザー・ツリーから検索するためです。このような問合せは、ユーザーがアプリケーションにログインしたり、使用したりするたびに、アプリケーションによって繰り返されます。このような問合せの結果セットは、単一エントリであることがあります。問合せが実行されるたびに、そのエントリを求めてOIDはデータベースを検索するため、パフォーマンスに影響が出ることがあります。
次の条件を満たす場合にのみ、結果セット・キャッシュの使用を検討してください。
フィルタが1つまたは少数のエントリと合致すること。
SQL文によってディスクまたはバッファから複数の読取りが発生すること(高コスト)
エントリ・キャッシュを使用する利点は次のとおりです。
OIDはデータベースを検索せずにフィルタを評価するため、データベースに対する負荷が軽減します。
結果セット・キャッシュのデータベース・パラメータは、クライアント側またはサーバー側で構成できることに注意してください。サーバー側のキャッシュが有効になっていると、結果セット・キャッシュは、膨大な量のデータベース・メモリーを消費できるため、OIDのパフォーマンスに影響が出る可能性があります。
結果セット・キャッシュを使用しないときのパフォーマンスと比較すると、パフォーマンスは3から5倍の影響を受けます。
次の構成属性に対する変更には、OIDサーバー(すべてのインスタンス)を再起動する必要があることに注意してください。
インスタンス固有の構成エントリ属性orcloptrackmaxtotalsize
およびorcloptracknumelemcontainers
は、セキュリティ・イベント追跡に使用するメモリー量を制御します。
属性orcloptrackmaxtotalsize
には、セキュリティ・イベント追跡で各タイプの操作に使用できるRAMの最大バイト数を指定します。ある操作に関して収集される情報について、この制限を超えると、ディレクトリ・サーバーは新しい情報の収集を停止し、該当するメッセージをサーバー・ログ・ファイルに記録します。比較操作の場合、ディレクトリ・サーバーではこの属性値の2倍のメモリーを使用します。これは、比較操作を実行するユーザーと、パスワードを比較されているユーザーに関する情報を合せた量です。orcloptrackmaxtotalsize
のデフォルト値は100000000バイトで、ほとんどのデプロイメントはこれで十分です。この値は200MBまで増やせます。orcloptrackmaxtotalsize
の変更の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項のインスタンス固有の構成属性の例を参照してください。
属性orcloptracknumelemcontainers
によって、Oracle Internet Directoryサーバーでセキュリティ・イベント追跡に割り当てるメモリー内キャッシュ・コンテナの数を選択できます。この属性にはサブタイプが2つあります。1stlevel
と2ndlevel
です。1stlevel
サブタイプでは、操作を実行するユーザーの情報を格納するためのメモリー内キャッシュ・コンテナの数を設定します。2ndlevel
サブタイプは比較操作にのみ適用されます。このサブタイプでは、詳細比較操作統計がプログラムされている場合に、ユーザー・パスワードが比較および追跡されるユーザーの情報を格納するためのメモリー内キャッシュ・コンテナの数を設定します。両サブタイプのデフォルト値は256
です。これらのサブタイプの適切な値は、次のように、環境内のユーザー数、およびディレクトリへのアクセスに使用されるアプリケーションの数によって異なります。
多数のエンドユーザーにかわって複数のアプリケーションが操作を実行するデプロイメントでは、アプリケーションの数にディレクトリに直接アクセスするエンドユーザー用の数百を足した数に比例して1stlevelを設定します。2ndlevelは、エンドユーザーの数に比例して設定します。
エンド・ユーザー自身が操作を行うデプロイメントでは、1stlevel
はエンド・ユーザーの数に比例して設定し、2ndlevel
は25などの小さい値に設定します。
通常、比例値は5分の1です。ほとんどの環境で10分の1から2分の1までの割合が適切です。
デプロイメントでの必要に応じて、セキュリティ・イベント収集が有効になっている場合にのみorcloptracknumelemcontainers
に値を設定します。
この項の内容は次のとおりです。
member
属性とuniquemember
属性のいずれかが数千の属性値を持つグループ・エントリの検索では、待機時間が長くなる可能性があります。待機時間が受け入れ難いほど長い場合は、これを減らせる方法があります。
最も簡単な方法は、検索する属性の数を減らすことです。グループ・エントリの属性をすべて取得する必要がないのであれば、待機時間を最適化するために検索リクエストに必須の属性を指定します。
必須の属性を指定してもまだ待機時間が長すぎる場合は、エントリ・キャッシュに大きいグループ・エントリをキャッシュします。そのためには、インスタンス固有の構成エントリのorclEcacheMaxEntSize
属性の値を増やします。
cn=componentname,cn=osdldapd,cn=subconfigsubentry
この属性は、キャッシュ・エントリの最大サイズを制御します。
注意: 大きいグループに対する更新が頻繁になることが予想される場合は、このチューニング方法を使用しないでください。エントリ・キャッシュを無効にした構成を使用します。 |
通常の検索リクエストを処理する場合、ディレクトリ・サーバーはSQL文をOracle Databaseに送信します。ある属性のレスポンス時間が属性の値によって大きく異なる場合、この属性はスキュー属性と呼ばれます。たとえば、my_attribute=value1
とmy_attribute=value2
の検索で、レスポンス時間が大きく異なる場合、my_attribute
はスキュー属性と呼ばれます。
このような属性を、DSA構成エントリにあるorclskewedattribute
属性の値として追加することにより、検索時のレスポンス時間を均一にできます。DSA構成エントリのDNは次のとおりです。
cn=dsaconfig,cn=configsets,cn=oracle internet directory
デフォルトでは、objectclass
属性はorclskewedattribute
属性内に値としてリストされます。
ldapmodify
を使用してorclskewedattribute
の値を変更できます。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
Oracle Internet Directoryは、クライアント・アプリケーションからLDAP検索フィルタを受け取ると、フィルタをSQL問合せとしてOracle Databaseに送信します。クライアント・アプリケーションから送られたフィルタに、ディレクトリ内の多数のエントリと一致する条件が含まれている場合があります。たとえば、次のようなフィルタがあるとします。
(&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE)
)
このフィルタの条件(objectclass=inetorgperson)
および(orclisenabled=TRUE)
は、ほとんどすべてのエントリと一致します。Oracle Databaseでのフィルタ全体の実行には非常に多くのリソースが必要になります。パフォーマンスを改善するために、Oracle Internet Directoryがデータベースではなく自身のメモリーでフィルタの一部を実行するよう指定できます。そのためには、DSA構成エントリの属性orclinmemfiltprocess
を使用します。
cn=dsaconfig,cn=configsets,cn=oracle internet directory
orclinmemfiltprocess
が構成されている場合、Oracle Internet DirectoryがLDAP検索を受け取るたびに、次のイベントが発生します。
Oracle Internet Directoryは、SQL問合せを形成する前に、orclinmemfiltprocess
に構成されているすべての条件を削除します。
Oracle Internet Directoryは、SQL問合せをOracle Databaseに送信します。
Oracle Databaseは、SQL問合せの結果のエントリをOracle Internet Directoryに送信します。
Oracle Internet Directoryは、クライアントから送信された元のフィルタ(orclinmemfiltprocess
の条件)をメモリー内のエントリに適用します。
Oracle Internet Directoryは、そのフィルタと一致するエントリをクライアントに送信します。
たとえば、orclinmemfiltprocess
が(objectclass=inetorgperson)(orclisenabled=TRUE)
に設定されているとします。Oracle Internet Directoryは、検索(&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE))
を受け取ると、パラメータ(uid=msmith)
のみを含むフィルタをデータベースに送信します。データベースから返されたエントリを受信すると、Oracle Internet Directoryはフィルタ(objectclass=inetorgperson) (orclisenabled=TRUE)
をこれらのエントリに適用します。
デフォルトでは、orclinmemfiltprocess
は次の値に設定されています。
(objectclass=inetorgperson)
(objectclass=oblixorgperson)
(|(!(obuseraccountcontrol=*))(obuseraccountcontrol=activated))
(|(obuseraccountcontrol=activated)(!(obuseraccountcontrol=*)))
(objectclass=*)
(objectclass=oblixworkflowstepinstance)
(objectclass=oblixworkflowinstance)
(objectclass=orcljaznpermission)
(obapp=groupservcenter)(!(obdynamicparticipantsset=*))
(objectclass=orclfeduserinfo)
ldapmodify
を使用してorclinmemfiltprocess
の値を変更できます。『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のインスタンス固有の構成エントリの属性に関する項および『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。
ある条件下では、Oracle Internet Directoryはorclinmemfiltprocess
を無視してフィルタ全体をデータベースに送信します。これが実行されるのは、受信するフィルタが次の条件を満たしている場合です。
1つのパラメータ、つまり1つの属性/値ペアのみで構成されていること。
orclinmemfiltprocess
で指定されている条件以外のフィルタ条件がないこと
orclinmemfiltprocess
で指定されている条件に適用されるOR条件があること
orclinmemfiltprocess
で指定されている条件と同じ条件が異なる順序で含まれていること
次の各例でこれらの条件について説明します。次の例ではすべて、orclinmemfiltprocess
が(objectclass=inetorgperson)(employeetype=Contract)
に設定されています。
例
例A
(&(manager=cn=john doe)(objectclass=inetorgperson) (employeetype=Contract))
Oracle Internet Directoryは、フィルタ(&(manager=cn=john doe))
をデータベースに送信します。
例B
(&(uid=rmsmith)((objectclass=inetorgperson)(employeetype=Contract)))
Oracle Internet Directoryは、(&(uid=rmsmith))
のみをデータベースに送信し、データベースから返されたエントリにフィルタ(&(objectclass=inetorgperson)(employeetype=Contract))
を適用します。
例C
(|(uid=rmsmith)(objectclass=inetorgperson) (employeetype=Contract))
このフィルタでは、orclinmemfiltprocess
と一致する条件がOR条件に含まれます。Oracle Internet Directoryは、このフィルタをそのままデータベースに送信します。
例D
(&(uid=rmsmith)(employeetype=Contract) (objectclass=inetorgperson))
このフィルタの条件の一部がorclinmemfiltprocess
と一致しても、条件の順序が異なるため、Oracle Internet Directoryはフィルタ全体をデータベースに送信します。Oracle Internet Directoryがこのフィルタをデータベースに送信しないようにするには、orclinmemfiltprocess
に(employeetype=Contract)(objectclass=inetorgperson)
を追加します。
例E
(|(&(uid=rmsmith)(sn=smith)(objectclass=inetorgperson)(employeetype=Contract))
このフィルタでは、orclinmemfiltprocess
と一致する条件がOR条件に含まれます。Oracle Internet Directoryは、このフィルタをそのままデータベースに送信します。
例F
(&(|(uid=rmsmith)(sn=smith))(objectclass=inetorgperson)(employeetype=Contract)))
このフィルタにOR演算子が含まれていても、フィルタはorclinmemfiltprocess
と一致する条件に適用されません。Oracle Internet Directoryは、(&(|(uid=rmsmith)(sn=smith)))
をディレクトリに送信し、データベースから返されたエントリにフィルタ(&(manager=cn=john doe)(&(objectclass=inetorgperson) (employeetype=Contract))
を適用します。
複数のフィルタの構成
アプリケーションが複数のフィルタを送信し、あるフィルタの条件が別のフィルタの条件のスーパーセットである場合は、両方の値に対してorclinmemfiltprocess
を構成する必要があります。たとえば、アプリケーションが次の2つのフィルタを送信するとします。
(&(uid=rmsmith)(objectclass=inetorgperson)(employeetype=Contract))
(&(uid=rmsmith)(objectclass=inetorgperson)(employeetype=Contract)(departmentNumber=627))
(departmentNumber=627)
は多くのエントリと一致します。orclinmemfiltprocess
を次のように構成する必要があります。
(objectclass=inetorgperson)(employeetype=Contract)
(departmentNumber=627)
検索ベースDNのパフォーマンスの最適化
DITでは、cn=users,dc=acme,dc=com
などの1つのベースDNにすべてのユーザーが存在する場合、すべてのLDAP検索クライアントがcn=users,dc=acme,dc=com
としてベースを送信するので、orclinmemfilter
の構成でデータベース処理時間が大幅に削減されます。次の例を参照してください。
orclinmemfiltprocess;dn: cn=users,dc=acme,dc=com
この項では、第23.3項「チューニングに関する基本的な考慮事項」に加えて、さらにチューニングが必要になる特殊なユースケースについて説明します。
大規模なbulkdelete
操作を予定している場合は、次のタスクを実行します。
データベース初期化パラメータsga_target
が、第23.3.1項「データベース・パラメータ」の説明に従ってチューニングされていることを確認します。
データベース初期化パラメータlog_buffer
を10Mに設定します。こうすると、パフォーマンス上の利点が増します。
100MB以上のデータベースREDOログ・ファイルが少なくとも3つあることを確認します。
UNDO表領域の合計サイズが1GB以上であることを確認します。
次の第23.5.3項「負荷の高いLDAP書込み操作」のREDOログおよびUNDO表領域に関する推奨事項に従います。
LDAP書込み操作の負荷が高い場合や、多くのbulkdelete
操作を実行する場合は、次の値のチューニングを検討します。
データベースREDOログ・ファイルのサイズまたは数を、合計サイズが1000から1500MBになるよう増やします。他に考慮すべき要素によってREDOログの合計サイズは変わります。
ディスクの構成によっては、REDOログ・ファイルを専用のディスク・セットに置くほうが効果的な場合があります。
データ・ファイルをUNDO表領域に追加することで、この表領域を大きくします。ほとんどのデプロイメントでは、2から4GBで十分です。
Oracle Internet Directoryのサーバー・エントリ・キャッシュは使用しないでください。第23.4.6項「サーバー・エントリ・キャッシュ」を参照してください。
Oracle Internet DirectoryレプリケーションもDIPもデプロイされていない場合、変更ログの生成を無効にします。第23.4.1項「レプリケーションまたはOracle Directory Integration Platform」を参照してください。
表23-7は、この項で説明したREDOログおよびUNDO表領域に関する推奨事項をまとめたものです。