| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11g リリース2 (11.1.2.3.0) E61953-01 |
|
 前 |
 次 |
この章では、インストールされている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ライクなオペレーティング・システムを使用している場合は、次の各ツールを理解しておくことをお薦めします。
| ツール | 説明 |
|---|---|
| top | システムでCPUを最も多く消費しているタスクを表示します。 |
| vmstat | Virtual Memory Managerなど、システムの様々な部分の実行統計を示します。 |
| mpstat | vmstatと同様の出力ですが、システム内の各種CPUにわたって分割して示します。これはSolarisでのみ使用可能です。 |
| iostat | 各種ディスク・コントローラからのディスクI/O統計を示します。 |
| sar | システムのアクティビティ情報を収集、報告または保存します。 |
Microsoft Windowsを使用している場合は、次のツールを理解しておくことをお薦めします。
| ツール | 説明 |
|---|---|
| Windowsパフォーマンス・モニター | システム内のイベントのカスタマイズされたビューを表示します。 |
| Windowsタスク・マネージャ | システムで実行されている主なタスクの大まかな出力(UNIXのtopと同様)を提供します。 |
Oracle Databaseを使用する場合は、次のツールを理解しておくことをお薦めします。
utlbstat.sqlおよびutlestat.sqlまたはstatspack
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 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インスタンス・パラメータの最小値
| パラメータ | 値 | 注意 |
|---|---|---|
|
|
1700M (32ビットのシステムの場合) |
ディレクトリ・サイズが100万エントリを超える場合や、I/Oレートが高い場合には、大きな値が必要になることがあります。64ビットのシステムでは、マシン上のOracle Databaseで使用できるRAMの最大60から70%まで増やすことができます。 |
|
|
1200M (32ビットのシステムの場合) |
ディレクトリ・サイズが100万エントリを超える場合や、I/Oレートが高い場合には、大きな値が必要になることがあります。64ビットのシステムでは、マシン上のOracle Databaseで使用できるRAMの最大60から70%まで増やすことができます。 |
|
|
300M |
|
|
|
100 |
|
|
|
500 |
|
|
|
300M |
大規模な |
|
|
1以上。 |
このパラメータは、Oracle Databaseアドバンスト・レプリケーション・ベースのマルチマスター・レプリケーションを使用している場合にのみチューニングします。 |
|
|
99以下 |
OracleRACデータベース・デプロイメントのRDBMS v10.1にのみ、このパラメータをチューニングします。 |
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 Directory Integration Platformまたはレプリケーションと一緒にOracle Internet Directoryをデプロイする場合、これらの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に示すパラメータを変更すれば、この構成をデプロイメント要件に合せて変更できます。
表23-4 ガベージ・コレクション構成パラメータ
| パラメータ | 値 | 注意 |
|---|---|---|
|
|
10日(240時間)未満 |
変更ログを保持する必要がない場合のみ |
|
|
6から12時間 |
これらの属性は、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項「チューニングに関する基本的な考慮事項」に加えて、さらにチューニングが必要になる特殊なユースケースについて説明します。
大規模なbulkload操作を予定している場合、次の変更を行います。
操作の間、データベース初期化パラメータpga_aggregate_targetを1から4GBに設定します(十分なRAMが使用可能な場合)。
多数のエントリをロードする前に、データベース一時表領域を大きくします。100万エントリのロードにつき、約1GBの一時表領域が必要になります。この一時表領域は、操作の完了後に解放できます。
大規模な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表領域に関する推奨事項をまとめたものです。
