1. パフォーマンスのチューニング・ガイド
  2. Oracle IdentityおよびAccess Management
  3. Oracle Internet Directoryのパフォーマンス・チューニング

11 Oracle Internet Directoryのパフォーマンス・チューニング

この章では、インストールされているOracle Internet Directoryのチューニングおよびサイズ設定のガイドラインを示します。

この項の内容は、次のとおりです。

親トピック: Oracle Identity and Access Management

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コンポーネントの監視方法の詳細は、「モニタリング」を参照してください。

親トピック: Oracle Internet Directoryのパフォーマンス・チューニング

UNIXシステムおよびWindowsシステムでのパフォーマンスの監視

Linux、Solaris、その他のUNIXライクなオペレーティング・システムを使用している場合は、次の各ツールを理解しておくことをお薦めします。

ツール 説明

top

システムでCPUを最も多く消費しているタスクを表示します。

vmstat

Virtual Memory Managerなど、システムの様々な部分の実行統計を示します。

mpstat

vmstatと同様の出力ですが、システム内の各種CPUにわたって分割して示します。これはSolarisでのみ使用可能です。

iostat

各種ディスク・コントローラからのディスクI/O統計を示します。

sar

システムのアクティビティ情報を収集、報告または保存します。

Microsoft Windowsを使用している場合は、次のツールを理解しておくことをお薦めします。

ツール 説明

Windowsパフォーマンス・モニター

システム内のイベントのカスタマイズされたビューを表示します。

Windowsタスク・マネージャ

システムで実行されている主なタスクの大まかな出力(UNIXのtopと同様)を提供します。

Oracle Databaseを使用する場合は、次のツールを理解しておくことをお薦めします。

オペレーティング・システム・ツール以外に、カスタマ環境で使用されているLDAPアプリケーションも待機時間やスループットの測定方法を提供しています。

さらに、様々なデータベースodsスキーマ・オブジェクトを分析して統計を見積もるために、$ORACLE_HOME/ldap/adminにあるデータベース統計収集ツール(oidstats.sql)が提供されています。「oidstats.sqlを使用したデータベース統計の更新」を参照してください。

親トピック: Oracle Internet Directoryのパフォーマンスの監視

oidstats.sqlを使用したデータベース統計の更新

データベース統計が自動的に更新され、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 Identity Managementリファレンス』のoidstats.sqlコマンド行ツールのリファレンス

親トピック: Oracle Internet Directoryのパフォーマンスの監視

パフォーマンス関連のレプリケーション構成属性の設定

レプリケーション属性を設定するには、Oracle Enterprise Manager Fusion Middleware Controlのレプリケーション・ウィザードまたはコマンド行を使用します。

属性orclthreadspersupplier、orclchangeretrycountおよびorclconflresolutionは、レプリケーション構成セット属性です。

関連項目:

次の情報については

属性orclhiqscheduleおよびorclupdatescheduleは、レプリケーション承諾エントリ属性です。

関連項目:

関連項目:

  • レプリケーション・ウィザードを使用したレプリケーション属性の設定の詳細は、『Oracle Internet Directoryの管理』のFusion Middleware Controlのレプリケーション・ウィザードを使用した一方向、双方向またはマルチマスターLDAPベースのレプリケーション承諾の設定に関する項。

  • 『Oracle Internet Directoryの管理』のldapmodifyを使用したレプリケーション構成セット属性の構成に関する項。

親トピック: Oracle Internet Directoryのパフォーマンスの監視

システム構成属性の管理

ほとんどのパフォーマンス関連のシステム構成属性は、Oracle Enterprise Manager Fusion Middleware Controlまたはコマンド行から設定できます。Oracle Directory Services Managerのデータ・ブラウザを使用してシステム構成属性を変更することもできます。

Oracle Internet Directoryのシステム構成属性の設定の詳細は、『Oracle Internet Directoryの管理』の「システム構成属性の管理」を参照してください:

親トピック: Oracle Internet Directoryのパフォーマンスの監視

ガベージ・コレクション構成属性の設定

属性orclpurgetargetageおよびorclpurgeintervalは、変更ログ・パージ構成エントリにあります。これらは、ldapmodifyまたはOracle Directory Services Managerを使用して変更できます。

親トピック: Oracle Internet Directoryのパフォーマンスの監視

ldapmodifyを使用した変更ログ・パージ属性の変更

次の例は、変更ログのパージの構成に使用するLDIFファイルです。

関連項目:

変更ログのパージの詳細は、『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 Internet Directoryの管理』の時間ベースの変更ログのパージの構成に関する項。

親トピック: ガベージ・コレクション構成属性の設定

Oracle Directory Services Managerでの変更ログのパージの変更

orclpurgetargetageおよびorclpurgeintervalは、Oracle Directory Services Managerのデータ・ブラウザを使用して変更できます。データ・ツリーで変更ログ・パージ構成エントリに直接移動することはできませんが、次のように拡張検索を使用すると可能です。

  1. 「データ・ブラウザ」タブで「拡張」をクリックします。

  2. 左ペインで「ガベージ・コレクション」を展開し、changelog purgeconfigを選択します。「ガベージ・コレクタ」ウィンドウが右ペインに表示されます。

  3. 右ペインで、パージのターゲット期間およびパージの間隔に加える変更を入力します。

  4. 「適用」を選択します。

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

チューニングとは、ディレクトリのパフォーマンスを改善するためにパラメータを調整することです。Oracle Internet Directoryのデフォルト構成は、ほとんどすべてのデプロイメントでチューニングを必要とします。この項に記載されている要件および推奨事項を十分に確認してください。

親トピック: Oracle Internet Directoryのパフォーマンス・チューニング

データベース・パラメータ

Oracle Databaseインスタンス・パラメータの推奨される最小値を表11-1に示します。

表11-1 Oracle Databaseインスタンス・パラメータの最小値

パラメータ 値 ノート

sga_targetと

sga_max_size

1700M (32ビットのシステムの場合)

sga_targetおよびsga_max_sizeを使用したSGA自動チューニングを使用している場合に適用されます。bulkdeleteのパフォーマンスにおいて特に重要です。

ディレクトリ・サイズが100万エントリを超える場合や、I/Oレートが高い場合には、大きな値が必要になることがあります。64ビットのシステムでは、マシン上のOracle Databaseで使用できるRAMの最大60から70%まで増やすことができます。

db_cache_size

1200M (32ビットのシステムの場合)

sga_targetおよびsga_max_sizeを使用したSGA自動チューニングを使用していない場合に適用されます。(このパラメータを使用せずに、sga_targetおよびsga_max_sizeを使用したSGA自動チューニングを行うことをお薦めします。)

ディレクトリ・サイズが100万エントリを超える場合や、I/Oレートが高い場合には、大きな値が必要になることがあります。64ビットのシステムでは、マシン上のOracle Databaseで使用できるRAMの最大60から70%まで増やすことができます。

shared_pool_size

300M

sga_targetおよびsga_maxsizeを使用したSGA自動チューニングを使用していない場合に適用されます。

session_cached_cursors

100

processes

500

pga_aggregate_target

300M

大規模なbulkload操作を実行する前に、この値を1から4GBに設定します(十分なRAMが使用可能な場合)。操作が完了したら、元の値に戻します。

job_queue_processes

1以上。

このパラメータは、アドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用している場合にのみチューニングします

max_commit_propagation_delay

99以下

Oracle RACデータベース・デプロイメントのRDBMS v10.1にのみ、このパラメータをチューニングします。

Oracle Databaseインスタンス・パラメータの設定の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照してください。

親トピック: チューニングに関する基本的な考慮事項

LDAPサーバー属性

表11-2に、この項の推奨事項の要約を示します。

  • LDAPアプリケーション・トラフィックを処理するOracle Internet Directoryサーバー・インスタンスのプロセスおよびスレッドの数をチューニングします。これは、全体的なパフォーマンスに大きな影響を与えます。表11-2のorclmaxccおよびorclserverprocsの推奨される設定を参照してください。

  • レプリケーションまたはOracle Directory Integration Platformをデプロイしない場合、変更ログの生成を無効にします。属性orclgeneratechangelogを0に設定します。

  • ディレクトリに参照エントリがない場合、LDAP検索で参照をスキップします。orclskiprefinsqlを1に設定します。これは、パフォーマンスに大きな影響を与える可能性があります。

  • アイドルLDAP接続を開いたままにせず、一定期間の経過後閉じます。こうすると、接続が必要以上に増えるのを防止できます。たとえば、orclldapconntimeoutを60分に設定します。

    これは、g (10.1.4.0.1)から、操作統計を追跡するよう構成されていないユーザーにしか設定できなくなりました。統計を収集するよう構成されているユーザーの接続は、この設定に従ってタイムアウトしません。

    関連項目:

    『Oracle Internet Directoryの管理』のFusion Middleware Controlを使用した統計収集のためのユーザーの構成に関する項。

  • LDAP検索操作のベースDNがディレクトリになく、クライアントが詳細なMatchDN情報を必要としない場合は、詳細なMatchDN情報を無効にします。orclmatchdnenabledを0に変更します。

次の値は、ほとんどのデプロイメントに適しています。

表11-2 LDAPサーバーの属性のチューニング

属性 デフォルト 推奨値 ノート

orclmaxcc

2

10

サーバーの再起動が必要です。

orclserverprocs

1

システムのCPUコアの数

orclskiprefinsql

0

1

この変更を行うことを強くお薦めします。LDAP参照エントリがある場合は変更しないでください。LDAP参照エントリは共通ではありません。

サーバーの再起動が必要です。

orclgeneratechangelog

1

0

レプリケーションまたはOracle Directory Integration Platformをデプロイしない場合にのみ、変更ログの生成を無効にします。

orclldapconntimeout

0 (タイムアウトなし)

場合によって異なる(一般的には60分)

統計を追跡するよう構成されているユーザーはタイムアウトしません。

orclmatchdnenabled

1

0

検索のベースDNが存在せず、アプリケーションが詳細なMatchDN情報を必要としない場合にのみ、無効にします。

Oracle Enterprise Manager Fusion Middleware Controlを使用したorclserverprocs、orclldapconntimeoutおよびorclmatchdnenabledの構成の詳細は、『Oracle Internet Directoryの管理』のインスタンス固有の構成エントリの属性に関する項を参照してください。

Oracle Enterprise Manager Fusion Middleware Controlを使用したorclskiprefinsqlまたはorclmatchdnenabledの構成の詳細は、『Oracle Internet Directoryの管理』の共有プロパティの構成に関する項を参照してください。

これらの属性およびorclgeneratechangelogのコマンド行からの構成の詳細は、『Oracle Internet Directoryの管理』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

親トピック: チューニングに関する基本的な考慮事項

データベース統計

LDAPコマンドを使用して多数のエントリをOracle Internet Directoryに追加すると、ディレクトリのパフォーマンスに影響が出ることがあります。その場合は、データベース統計を更新します。「oidstats.sqlを使用したデータベース統計の更新」を参照してください。

通常、この操作が必要になるのは、Oracle Internet Directoryのインストール後に初めてエントリをバルクで追加する場合のみです。データベース統計は夜間に自動的に更新されるため、この操作を再度実行する必要はありません。ただし、データ・フットプリントを変更していないのにLDAP操作が突然遅くなった場合は、一度oidstats.sqlを実行してパフォーマンスが改善するかどうか確認することを検討してください。データベースSQL実行計画の変更が原因で影響が出ている可能性があります。この場合は、oidstats.sqlによって改善します。

bulkloadツールを使用してエントリを追加する場合、データベース統計の更新は不要です。データベース統計は、bulkloadコマンドによって自動的に更新されます。

親トピック: チューニングに関する基本的な考慮事項

チューニングに関する優先度の低い考慮事項

この項では、パフォーマンスを改善することはあるが、優先度が低いとみなされている属性について説明します。

親トピック: チューニングに関する基本的な考慮事項

検索で返されるエントリの数

属性orclsizelimitは、検索で返されるエントリの最大数を制御します。デフォルト値は10000です。この値を非常に大きくすると、サーバーのパフォーマンスに影響が出ます。また、レプリケーション・サーバーが一度に処理できる変更ログの最大数を制限する役割も果します。

『Oracle Internet Directoryの管理』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

グループ・キャッシュの有効化

インスタンス固有のサブエントリ属性orclenablegroupcacheは、権限グループおよびACLグループをキャッシュするかどうかを制御します。このキャッシュを使用すると、ユーザーのアクセス制御評価のパフォーマンスが向上します。

グループ・キャッシュは、権限グループ・メンバーシップが頻繁に変更されない場合に使用してください。権限グループ・メンバーシップが頻繁に変更される場合は、グループ・キャッシュをオフにすることをお薦めします。これは、グループ・キャッシュを計算する処理がパフォーマンスに影響を与えるためです。デフォルトは1(有効)です。0(ゼロ)に変更すると、無効になります。

『Oracle Internet Directoryの管理』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

書込み操作のタイムアウト

LDAPクライアントが操作を開始した後、構成された秒数の間サーバーに応答しないと、サーバーは接続をクローズします。この秒数は、インスタンス固有の構成エントリのorclnwrwtimeout属性によって制御されます。デフォルトは30秒です。

orclnwrwtimeoutの変更には、Fusion Middleware Controlまたはコマンド行を使用できます。『Oracle Internet Directoryの管理』のインスタンス固有の構成エントリの属性に関する項。

チューニングに関する高度な考慮事項

前の項で推奨されている変更を行った後、デプロイメントに固有の変更をさらに行うことができます。この項の推奨事項は、ご使用の環境に適しているかどうか慎重に検討してください。

親トピック: Oracle Internet Directoryのパフォーマンス・チューニング

レプリケーションまたはOracle Directory Integration Platform

Oracle Internet DirectoryをOracle Directory Integration Platformまたはレプリケーションとともにデプロイする際には、この2つのサーバー専用のLDAPサーバー・インスタンスを使用すると、パフォーマンスが向上します。この場合、デフォルトのOracle Internet Directory LDAPインスタンスでLDAPアプリケーションのトラフィックを処理し、2番目のインスタンスでレプリケーション・サーバーおよびOracle Directory Integration PlatformサーバーからのLDAPリクエストを処理することができます。

  1. 『Oracle Internet Directoryの管理』のOracle Internet Directoryインスタンスの管理に関する項の説明に従って、追加のサーバー・インスタンスを作成します。
  2. 新しいインスタンス構成で、orclmaxccを10に、orclserverprocsを1に設定します。
  3. 『Oracle Internet Directoryの管理』の「Oracle Internet Directoryインスタンスの管理」の説明に従って、サーバーを再起動します。
  4. 新しいインスタンスが使用するSSLポートおよび非SSLポートを設定し、レプリケーションおよびOracle Directory Integration Platformがこれらのポートを指し示すように構成します。

orclmaxccおよびorclserverprocsを構成するには、『Oracle Internet Directoryの管理』のインスタンス固有の構成エントリの属性に関する項と、『Oracle Internet Directoryの管理』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

ノート:

Oracle Internet Directoryクラスタ構成(ラックマウントまたはマルチボックス)では、レプリケーション・サーバーを1つのハードウェア・ノードでのみ起動する必要があります。レプリケーション専用のLDAPサーバー・インスタンスは、それと同じノードで起動してください。Oracle Directory Integration Platformサーバーは、別のノードにあってもかまいません。

親トピック: チューニングに関する高度な考慮事項

レプリケーション・サーバー構成

次の推奨事項は、レプリケーション・トラフィックが多い場合に役立ちます。変更を行う前に、必ずトレードオフを理解しておいてください。推奨値は、表11-3にまとめてあります。

  • 読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合、競合解決をオフにすると、パフォーマンスへの影響を軽減できます。これを行うには、orclconflresolutionの値を0にします。

  • サプライヤがボトルネックの場合、サプライヤのorclthreadspersupplierを増やします。コンシューマがボトルネックになっている場合も、コンシューマのorclthreadspersupplierを増やせますが、並列度が高まることによって変更ログの適用時に競合状態が生じ、結果的に管理者操作キュー(HIQ)の変更が増加することに注意してください。

  • 新規変更ログのリソースが増えるようorclchangeretrycountを減らします。ただし、競合が発生している場合は、これによって管理者操作キュー(HIQ)の変更が増加します。

  • orclupdatescheduleを0に変更して、サーバー・プロセスの変更ログが60秒おき(デフォルト)ではなく、ただちに作成されるようにします。これは、サプライヤとコンシューマの両方で行います。

  • orclhiqscheduleの値を大きくします。たとえば、管理者操作キュー(HIQ)に1日4回アクセスすれば十分であり、デプロイメントにもそれが適している場合は、orclhiqscheduleを21600秒(6時間)に設定します。

表11-3は、これらの推奨事項をまとめたものです。

表11-3 レプリケーション属性

属性 デフォルト 推奨値 ノート

orclthreadspersupplier

転送=1

適用=5

転送スレッドを1に、適用スレッドを10以上に設定

サプライヤがボトルネックになっている場合に最も有効です。

orclchangeretrycount

10

4

変更ログのリソースが増えますが、HIQが増加することがあります。

orclupdateschedule

60秒

0

変更ログがただちに処理されます。

orclhiqschedule

600秒

21600秒

新しい変更を処理するためのリソースが増えます。

orclconflresolution

1

0

読取り専用のレプリカ・コンシューマを持つ単一のマスターをデプロイする場合にのみ変更します。

これらのレプリケーション属性の設定の詳細は、「パフォーマンス関連のレプリケーション構成属性の設定」を参照してください。

親トピック: チューニングに関する高度な考慮事項

ガベージ・コレクション構成

デフォルトでは、Oracle Internet Directoryはデータベース・ジョブを実行して、変更ログ、サーバー管理性統計、その他のデータをパージします。各ジョブは、午前0時から15分間隔で開始されます。表11-4に示すパラメータを変更すれば、この構成をデプロイメント要件に合せて変更できます。

表11-4 ガベージ・コレクション構成パラメータ

パラメータ 値 ノート

orclpurgetargetage

10日(240時間)未満

変更ログを保持する必要がない場合のみ

orclpurgeinterval

6–12時間

これらの属性は、ldapmodifyまたはOracle Directory Services Managerを使用して変更できます。「ガベージ・コレクションの構成属性の設定」を参照してください。

親トピック: チューニングに関する高度な考慮事項

Oracle Internet DirectoryとRACデータベース

「レプリケーション・サーバー構成」で説明したとおり、デフォルトのサーバーに加えて、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では、パスワード・ポリシーおよびパスワード検証プロファイルがデフォルトで有効になっています。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倍速くなることがあります。これは、エントリのすべて、または大半がキャッシュ可能な場合にのみ当てはまります。キャッシュ・ミスは、エントリ・キャッシュを無効にするよりコストがかかります。

エントリ・キャッシュを構成するための値

サーバー・エントリ・キャッシュは、表11-5に示す値を設定することで構成および最適化できます。

表11-5 サーバー・エントリ・キャッシュの構成

属性 デフォルト 推奨値 ノート

orclmaxcc

2

10

この属性を変更した後、サーバーを再起動します。

orclserverprocs

1

システムのコアの総数。

orclecacheenabled

2

2

orclecachemaxsize

200000000バイト

ディレクトリの合計サイズ(バイト)

この属性の最適な設定を決定するには、ディレクトリ情報ツリーのエントリ数を使用し、その数に平均エントリ・サイズを掛けます。

LDIF形式のエントリ・サイズの3倍の見積りをしてください。

orclecachemaxentries

100000

DIT内のエントリ総数

orclecachemaxentsize

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 Internet Directoryの管理』のインスタンス固有の構成エントリの属性に関する項と、『Oracle Internet Directoryの管理』のldapmodifyを使用したシステム構成属性の設定に関する項を参照してください。

結果セット・キャッシュ

結果セット・キャッシュにより、完全な結果セットをメモリーに格納できます。SQL問合せが実行され、その結果セットがキャッシュ内に存在する場合、SQL実行のオーバーヘッドはほぼすべて回避されます。これには、解析時間、論理読取り、物理読取り、および通常発生するキャッシュ競合オーバーヘッド(ラッチなど)が含まれます。結果キャッシュを構成すると、パフォーマンスが向上する可能性がありますが、これは、ほとんどのLDAPアプリケーションが、mail=john.doe@example.comやuid=john.doeなどのユーザー・エントリをユーザー・ツリーから検索するのが一般的なためです。このような問合せは、ユーザーがアプリケーションにログインしたり、使用したりするたびに、アプリケーションによって繰り返されます。結果セットは、単一エントリの場合があります。問合せが実行されるたびに、そのエントリを求めてOIDはデータベースを検索するため、パフォーマンスに影響が出ることがあります。

親トピック: チューニングに関する高度な考慮事項

結果セット・キャッシュを使用する条件

次の条件を満たす場合にのみ、結果セット・キャッシュの使用を検討してください。

  • フィルタが1つまたは少数のエントリと合致すること。

  • SQL文によってディスクまたはバッファから複数の読取りが発生すること(高コスト)

結果セット・キャッシュを使用する利点

エントリ・キャッシュを使用する利点は次のとおりです。

  • OIDはデータベースを検索せずにフィルタを評価するため、データベースに対する負荷が軽減します。

    結果セット・キャッシュのデータベース・パラメータは、クライアント側またはサーバー側で構成できることに注意してください。サーバー側のキャッシュが有効になっていると、結果セット・キャッシュは、膨大な量のデータベース・メモリーを消費できるため、OIDのパフォーマンスに影響が出る可能性があります。

  • 結果セット・キャッシュを使用しないときのパフォーマンスと比較すると、パフォーマンスは3から5倍の影響を受けます。

結果セット・キャッシュの構成

OrclRSCacheAttr属性を使用して、OID用の結果セット・キャッシュを構成します。OrclRSCacheAttrは、cn、mail、uidおよびorclguidを含む複数値属性です。通常、これらの属性はエントリの存続期間中変更できません。

結果セット・キャッシュを有効化するには、orclecacheenabled=2を設定します。結果セット・キャッシュは、orclecacheenabled=1またはorclecacheenabled=0を設定すると無効化できます。

これらの構成属性を変更した場合は、OIDサーバー(すべてのインスタンス)を再起動する必要があります。

結果セット・キャッシュを構成するための値

次の構成属性に対する変更には、OIDサーバー(すべてのインスタンス)を再起動する必要があることに注意してください。

表11-6 チューニングする結果セット・キャッシュ属性

属性 デフォルト 推奨値 ノート

OrclRSCacheAttr

cn、mail、uid、orclguid

複数値属性。値には属性の名前が含まれます。通常、これらの属性はエントリの存続期間中変更できません。

ResultSetMaxEntries

4

特定の検索に対する、キャッシュ可能なエントリの最大数。

ResultSetMaxCacheSize

10MB

結果セット・キャッシュの共有メモリーで割当て可能な最大メモリー。

ResultSetMaxTime

8時間

キャッシュが満杯になったときの結果セット・キャッシュの存続時間。

セキュリティ・イベント追跡のチューニング

インスタンス固有の構成エントリ属性orcloptrackmaxtotalsizeおよびorcloptracknumelemcontainersは、セキュリティ・イベント追跡に使用するメモリー量を制御します。

属性orcloptrackmaxtotalsizeには、セキュリティ・イベント追跡で各タイプの操作に使用できるRAMの最大バイト数を指定します。ある操作に関して収集される情報について、この制限を超えると、ディレクトリ・サーバーは新しい情報の収集を停止し、該当するメッセージをサーバー・ログ・ファイルに記録します。比較操作の場合、ディレクトリ・サーバーではこの属性値の2倍のメモリーを使用します。これは、比較操作を実行するユーザーと、パスワードを比較されているユーザーに関する情報を合せた量です。orcloptrackmaxtotalsizeのデフォルト値は100000000バイトで、ほとんどのデプロイメントはこれで十分です。この値は200MBまで増やせます。orcloptrackmaxtotalsizeの変更の詳細は、『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 Internet Directoryの管理』のインスタンス固有の構成エントリの属性に関する項と、『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検索を受け取るたびに、次のイベントが発生します:

  1. Oracle Internet Directoryは、SQL問合せを形成する前に、orclinmemfiltprocessに構成されているすべての条件を削除します。
  2. Oracle Internet Directoryは、SQL問合せをOracle Databaseに送信します。
  3. Oracle Databaseは、SQL問合せの結果のエントリをOracle Internet Directoryに送信します。
  4. Oracle Internet Directoryは、クライアントから送信された元のフィルタ(orclinmemfiltprocessの条件)をメモリー内のエントリに適用します。
  5. Oracle Internet Directoryは、そのフィルタと一致するエントリをクライアントに送信します。

たとえば、orclinmemfiltprocessが(objectclass=inetorgperson)(orclisenabled=TRUE)に設定されているとします。Oracle Internet Directoryは、検索(&(uid=msmith)(objectclass=inetorgperson)(orclisenabled=TRUE))を受け取ると、パラメータ(uid=msmith)のみを含むフィルタをデータベースに送信します。Oracle Internet Directoryがデータベースから返されたエントリを受信すると、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 Internet Directoryの管理』のインスタンス固有の構成エントリの属性に関する項と、『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

親トピック: 検索の最適化

追加のチューニングを必要とする特殊なユースケース

この項では、「チューニングに関する基本的な考慮事項」に加えて、さらにチューニングが必要になる特殊なユースケースについて説明します。

親トピック: Oracle Internet Directoryのパフォーマンス・チューニング

バルク・ロード操作

大規模なbulkload操作を予定している場合、次の変更を行います。

  • 操作の間、データベース初期化パラメータpga_aggregate_targetを1から4GBに設定します(十分なRAMが使用可能な場合)。

  • 多数のエントリをロードする前に、データベース一時表領域を大きくします。100万エントリのロードにつき、約1GBの一時表領域が必要になります。この一時表領域は、操作の完了後に解放できます。

親トピック: 追加のチューニングを必要とする特殊なユースケース

バルク削除操作

大規模なbulkdelete操作を予定している場合、次のタスクを実行します。

  • データベース初期化パラメータsga_targetが、「データベース・パラメータ」の説明に従ってチューニングされていることを確認します。

  • データベース初期化パラメータlog_bufferを10Mに設定します。こうすると、パフォーマンス上の利点が増します。

  • 100MB以上のデータベースREDOログ・ファイルが少なくとも3つあることを確認します。

  • UNDO表領域の合計サイズが1GB以上であることを確認します。

  • 次の「負荷の高いLDAP書込み操作」のREDOログおよびUNDO表領域に関する推奨事項に従います。

親トピック: 追加のチューニングを必要とする特殊なユースケース

負荷の高いLDAP書込み操作

LDAP書込み操作の負荷が高い場合や、多くのbulkdelete操作を実行する場合は、次の値のチューニングを検討します。

  • データベースREDOログ・ファイルのサイズまたは数を、合計サイズが1000から1500MBになるよう増やします。他に考慮すべき要素によってREDOログの合計サイズは変わります。

  • ディスクの構成によっては、REDOログ・ファイルを専用のディスク・セットに置くほうが効果的な場合があります。

  • データ・ファイルをUNDO表領域に追加することで、この表領域を大きくします。ほとんどのデプロイメントでは、2から4GBで十分です。

  • Oracle Internet Directoryのサーバー・エントリ・キャッシュは使用しないでください。「サーバー・エントリ・キャッシュ」を参照してください。

  • Oracle Internet DirectoryレプリケーションもDIPもデプロイされていない場合、変更ログの生成を無効にします。「レプリケーションまたはOracle Directory Integration Platform」を参照してください。

表11-7は、この項で説明したREDOログおよびUNDO表領域に関する推奨事項をまとめたものです。

表11-7 REDOログおよびUNDO表領域の値

属性 値 ノート

REDOログ

3つのログ(それぞれ100MB)

多数のbulkdelete操作。

REDOログ

合計サイズ1000から15000MB

多数の書込み操作。

UNDO表領域

合計で1GB以上

多数のbulkdelete操作。

UNDO表領域

2-4 GB

多数の書込み操作。

親トピック: 追加のチューニングを必要とする特殊なユースケース