20
ディレクトリの容量計画

容量計画は、アプリケーションのディレクトリ・アクセス要件を評価し、許容速度でリクエストを処理するための十分なコンピュータ・リソースがOracle Internet Directoryにあることを確認するプロセスです。この章では、容量計画を行うときに考慮する必要がある項目について説明します。Acme Corporationという仮想の会社における、電子メール・メッセージ・アプリケーションのディレクトリ配置例を使用して説明します。

この章では、次の項目について説明します。

容量計画の説明

Oracle Internet Directoryとそれに対応するOracle Databaseが同じコンピュータ上で実行されている場合、容量計画の担当者が考慮する必要がある設定可能なリソースは次のとおりです。

I/Oサブシステム（タイプとサイズ）
メモリー
ネットワーク接続性
CPU（スピードと数量）

Oracle Internet Directory用のハードウェアを調達する場合は、すべてのコンポーネント（CPU、メモリー、I/Oなど）が、効果的に使用されることを確認してください。一般的に、適切なメモリーの使用と堅固なI/Oサブシステムによって、CPUをビジー状態に保つことができます。

Oracle Internet Directoryを新規インストールする場合は常に、次の事項が整っている必要があります。

負荷率のピーク時にユーザーの要求を満たすための十分なハードウェア・リソースが用意されていること。
使用可能なリソースを最大限に活用し、使用可能なハードウェアから最大のパフォーマンスを引き出すために、適切にチューニングされたシステム（ハードウェアおよびソフトウェア）が用意されていること。

表20-1に、この章で使用する重要な用語を定義します。

表20-1 容量計画の用語

用語	定義
スループット	Oracle Internet Directoryがディレクトリ操作を完了する包括的な率。通常、操作/秒（1秒当りの操作件数）で表されます。
待機時間	指定したディレクトリ操作が完了するまでのクライアントの待機時間。
同時クライアント	Oracle Internet Directoryとのセッションを確立しているクライアントの総数。
同時操作	すべての同時クライアントの要求に基づいてディレクトリで実行されている同時操作の数。一部のクライアントではセッションがアイドル状態の可能性があるため、この数は同時クライアントの数と必ずしも同じではありません。

この章では、Acme Corporationという仮想の会社における、電子メール・メッセージ・アプリケーションのディレクトリ配置例を考察します。容量計画の各コンポーネントを検証し、Acme Corporationの例に対して推奨事項を適用していきます。

ディレクトリの使用パターンの理解: 事例

Oracle Internet Directoryの潜在的な負荷を評価することは、正確な容量計画を作成するために非常に重要です。Acme Corporationという仮想の会社で利用されている電子メール・メッセージ・ソフトウェアについて検証します。この例の電子メール・メッセージ・ソフトウェアは、Internet Message Access Protocol（IMAP）をベースにしています。Oracle Internet Directoryにアクセスする主要なソフトウェアには、次の2種類があります。

IMAPクライアント。IMAPサーバーにメールを送信する前に、会社内の電子メール・アドレスを検証します。このクライアントには、Netscape MessengerやMicrosoft Outlookなどのソフトウェア・プログラムが組み込まれています。
メッセージ・ソフトウェア。メール転送エージェント（MTA）とも呼ばれます。ディレクトリを調べて、社内メールを会社全体の配布リストに送信し、外部からのメールを社内のメールボックスに送信します。

個々のユーザーのプライベート・エイリアスとプライベート配布リストもディレクトリに格納されていると仮定します。さらに、表20-2の仮定を設けて、ディレクトリのサイズを推測できるようにします。

表20-2 エントリのタイプとサイズについての前提事項

エントリ・タイプ	サイズ
ユーザー数の合計	40,000
ユーザーごとのプライベート・エイリアスの平均数	10
ユーザーごとのプライベート配布リストの平均数	10
パブリック配布リストの合計数	4000
社内におけるパブリック・エイリアスの合計数	1000
このアプリケーションに関連しているディレクトリ内の各エントリにある属性数	20
カタログ化属性の数	10

前述の仮定に基づくと、Oracle Internet Directoryにおける全体的なエントリ件数は、表20-3のように算出できます。

表20-3 全体的なエントリ件数

エントリ・タイプ	サイズ
ユーザー・エントリ	40,000（このエントリはユーザー自身を表しています）
ユーザーのプライベート・エイリアス	40,000×10 = 400,000エントリ
ユーザーのプライベート配布リスト	40,000×10 = 400,000エントリ
会社全体の配布リスト	4000
会社全体のエイリアス	1000

前述の仮定から、ディレクトリに存在するエントリは約100万件であることがわかります。ユーザー数とディレクトリに存在するエントリ数が与えられたとして、パフォーマンス要件を導出するために、使用パターンを分析してみます。一般的なユーザーは、毎日平均10通の電子メールを送信し、外部から1日に平均10通の電子メールを受信します。ユーザーが送信する各メールに対して、平均5人の受信者がいると仮定すると、各メールごとに5回ずつディレクトリ参照が行われます。

表20-4は、1日に発生する可能性があるすべてのディレクトリ参照回数を要約したものです。

表20-4 1日のディレクトリ参照の数

ディレクトリ参照のタイプ	1日のディレクトリ参照の数
各ユーザーからの送信メールを処理するメール転送エージェント（MTA）	5×10×40,000 = 2,000,000
外部からのメールを処理するMTA	10×40,000 = 400,000
その他のすべてのディレクトリ参照（IMAPクライアントによる特定のアドレスの検証など）	800,000

合計すると、毎日のディレクトリ参照の総数は約3,200,000（320万）となります。これらの参照が1日に均一に分配されたとすると、毎秒約37ディレクトリ参照（毎時約133,333参照）が行われる必要があります。ただし、このように均一に分配されることは実際にはありません。

現行の電子メール・システムの使用状況を24時間にわたって分析すると、そのパターンは図20-1のようになります。

図20-1 現行電子メール・システムの使用状況の分析

画像の説明

電子メール・システムおよびOracle Internet Directoryに最も負荷がかかるのは朝の時間帯です。その他に、昼食時と就業時間終了付近にもピークがあります。しかし、Oracle Internet Directoryに最も負荷がかかるのは朝の時間帯です。

全ディレクトリ参照の90パーセントが通常の勤務時間内に発生すると仮定します。表20-5に、8時間勤務制の朝、昼食時、就業時間終了付近の負荷の時間帯を示します。

表20-5 勤務時間内の負荷

負荷の時間帯	参照回数
朝の負荷	65%: 0.90×0.65×3,200,000 = 1,872,000参照/2時間（936,000参照/時）
昼食時の負荷	10%: 0.90×0.10×3,200,000 = 288,000参照/1時間（288,000参照/時）
就業時間終了付近の負荷	20%: 0.90×0.20×3,200,000 = 576,000参照/2時間（288,000参照/時）

これらの計算結果により、この場合のディレクトリは、ピーク時の負荷である1時間当り936,000の参照を処理するように設計する必要があることが示されています。

データ・セットのサイズとパフォーマンス要件について理解したため、インストールの個々のコンポーネントを調べ、それぞれについて適切な値を見積もることができます。

I/Oサブシステムの要件

この項では、次の項目について説明します。

I/Oサブシステムの説明

I/Oサブシステムは、CPUが負荷となる作業を実行できるように、CPUにデータを送り出すポンプにたとえることができます。I/Oサブシステムには、データ記憶域を管理する役割もあります。I/Oサブシステムの主なコンポーネントは、ディスク・コントローラによって制御される一連のディスク・ドライブです。

I/Oサブシステムのサイズを決めるときは、記憶要件のみに基づいたサイズではなく、パフォーマンス要件を考慮することが重要です。ディスク・ドライブのサイズは増加していますが、スループット（ディスク・ドライブがデータを送り出す速度）は、比例して増加していません。I/Oサブシステムのサイズを計算するときには、情報として次の要因を考慮する必要があります。

データベースのサイズ
システム上のCPUの数
Oracle Internet Directoryの作業負荷の初期見積り
ディスクがデータを送出できる速度
ロード前のデータ準備に必要な領域
索引作成とソート作業に必要な領域

様々なI/Oサブシステムがある場合は、常にスループットが最大のドライブを選択してください。一般的に、次の技術を1つ以上使用すると、I/Oスループットを最大にできます。

I/O操作で複数のディスク・スピンドルを使用するために、論理ボリュームをストライプ化
異なる表領域を、異なる論理ディスク・ボリュームと物理ディスク・ボリュームに格納
ディスク・ボリュームを複数のI/O制御装置に分散

Oracle Internet Directory固有のデータ・ファイルを適切に動作させる方法のガイドラインは、第21章「ディレクトリのチューニングに関する考慮事項」を参照してください。ディスク障害の許容度によっては、異なるレベルのRedundant Arrays of Inexpensive Disks（RAID）を考慮することもできます。

可能なかぎり最良のI/Oサブシステムを用意する決定が行われたと仮定して、次にディスク自体のサイズ設定を見積ります。

ディスク領域要件の概算

表20-6を使用すると、全般的なディスク要件を概算で見積もることができます。

表20-6 ディスク領域要件

ディレクトリ情報ツリー内のエントリ数	ディスク要件
100,000	450MB～650MB
200,000	850MB～1.5GB
500,000	2.5GB～3.5GB
1,000,000	4.5GB～6.5GB
1,500,000	6.5GB～10GB
2,000,000	9GB～13GB

表20-6に示すデータから、次のことが仮定されます。

カタログ化属性が約20個であること
各エントリの属性が約25個であること
属性の平均サイズが約30バイトであること

Acme Corporationの例に戻ると、ディレクトリに存在するエントリ数は約100万であるため、ディスク要件はおよそ4.5GB～6.5GBとなります。カタログ化属性の数に関してAcme Corporationに設定した仮定は異なりますが、前述の表からサイズ要件の概算値を導出できます。

ディレクトリは、様々なアプリケーションに幅広く配置されている可能性があるため、これらの仮定は、考えられる状況すべてに対して必ずしも真である必要はありません。属性のサイズが大きい場合、エントリごとの属性の数が多い場合、アクセス制御情報アイテム（ACI）が広範囲で使用されている場合、またはカタログ化属性の数が非常に多い場合など、様々な状況が考えられます。このような場合の簡単な計算方法を、次項で提示します。この方法によって、計画担当者はディスク要件を詳細に把握できます。

ディスク領域要件の詳細な計算

Oracle Internet DirectoryはすべてのデータをOracle Databaseに格納するため、ディスク領域のサイズ設定では、主に基礎となるデータベースのサイズを設定します。Oracle Internet Directoryは、データを表20-7に示す表領域に格納します。

表20-7 Oracle Internet Directoryデータを格納するために使用する表領域

表領域名	内容
`OLTS_ATTR_STORE`	ディレクトリ情報ツリー内にある全エントリのすべての属性を格納。
`OLTS_CT_STORE`	その他のすべてのカタログ（ユーザー定義カタログを含む）およびカタログに定義されている索引を格納。
`OLTS_DEFAULT`	Oracle Internet Directoryの管理に関連するデータとレプリケーション・サポートに使用するデータをすべて格納。
`OLTS_SVRMGSTORE`	Oracle Internet Directoryサーバー管理機能に必要なすべての表と索引を格納。
`SYSTEM`	各種の記録保持の目的で、Oracle Databaseに必要。通常、このサイズは約300MBで一定です。

この項では、表20-7で参照される各表領域のサイズ要件を決定するための簡単な計算方法を提示します。すべてのサイズの計算は、表20-8の変数に基づいて行われます。

表20-8 サイズ計算に使用する変数

変数名	説明
num_entries	ディレクトリ内のエントリの合計数。
attrs_per_entry	ディレクトリ・エントリごとの属性の平均数。
avg_attr_size	属性値の平均サイズ（バイト）。
avg_dn_size	属性の識別名の平均サイズ（バイト）。
objectclass_per_entry	エントリが属しているオブジェクト・クラスの平均数。
objectclass_size	各オブジェクト・クラス名の平均サイズ（バイト）。
num_cataloged_attrs	エントリ内で使用されているカタログ化属性の数。
entries_per_catalog	カタログ表ごとのエントリの平均数。ディレクトリ情報ツリー内の全エントリにカタログ化属性が存在しているとはかぎらないため、この変数は必須です。
change_log_capacity	レプリケーション目的のためにバッファする変更の数。
num_acis	ディレクトリ内のACIの全体数。
num_auditlog_entries	ディレクトリに格納する監査ログ・エントリの数。
db_storage_ovhd	表にデータを格納するときのオーバーヘッド。このオーバーヘッドは、オペレーティング・システム固有のオーバーヘッドと同時に、関係する構造体にも該当します。この変数の値が1.3の場合は、30%のオーバーヘッドがあることを示しています。この変数の最小値は1です。
db_index_ovhd	索引にデータを格納するときのオーバーヘッド。このオーバーヘッドは、オペレーティング・システム固有のオーバーヘッドと同時に、関係する構造体にも該当します。この変数の値が5の場合は、400%のオーバーヘッドがあることを示しています。この変数の最小値は1です。
factor_of_safety	データ量の増加および計算誤差に対応するための乗数。この変数の値が1.3の場合は、安全係数が30%であることを示しています。この変数の最小値は1です。
initial_num_entries	ディレクトリに最初にバルク・ロードされるエントリの合計数。
avg_attrname_len	属性名の平均サイズ（バイト）。
num_stats_entries	ホストDSF属性orclstatsflagが使用可能な場合に、OIDサーバー管理機能によって生成される統計エントリの数。
attrs_per_stats_entry	統計エントリごとの属性の平均数。

表20-8に示す変数を使用すると、個々の表領域のサイズを表20-9に示すように計算できます。

表20-9 個々の表領域のサイズ

表が含まれている表領域	式
ATTRSTORE_INDEX_SIZE	num_entries(attrs_per_entry+6) 10
CATALOG_INDEX_SIZE	entries_per_catalognum_cataloged_attrsavg_attr_sizedb_index_ovhd +num_entriesobjectclass_per_entryobjectclass_sizedb_index_ovhd + num_acis1.5avg_dn_sizedb_index_ovhd + num_auditlog_entries2avg_dn_sizedb_index_ovhd
CN_SIZE	num_entriesavg_dn_sizedb_storage_ovhd
DN_INDEX_SIZE	num_entries2(avg_dn_size * 3)
DN_SIZE	num_entries2(avg_dn_size+4)
OBJECTCLASSES_SIZE	num_entriesobjectclass_per_entryobjectclass_sizedb_storage_ovhd + num_auditlog_entries2avg_dn_sizedb_storage_ovhd
OLTS_ATTR_STORE	(num_entries(((attrs_per_entry)(avg_attrname_len+avg_attr_size+22))+635)db_storage_ovhd)+attrstore_index_size
OLTS_BATTRSTORE	6M+(((num_binary_attrsavg_binval_length)+635)*db_storage_ovhd)
OLTS_CT_STORE	(cn_size+objectclasses_size+dn_size+catalog_index_size+dn_index_size)
OLTS_DEFAULT	(change_log_capacity4avg_attr_sizedb_storage_ovhddb_index_ovhd) + (initial_num_entries2(avg_dn_size+4))
OLTS_SVRMGSTORE	2M+num_stats_entries((avg_attrname_len+avg_attr_size+20)(2attrs_per_stats_entry)db_storage_ovhd(orclstatsperiodicity/10)12)
SYSTEM	300MB

この表の計算式は、Oracle Internet Directoryの広範囲にわたる様々な配置例についての正確な領域要件を計算するために使用します。各表領域のサイズを合計すると、データベース全体のディスク要件がわかります。オプションで、その値にfactor_of_safety変数を乗算すると、予期せぬ事態にも対処可能な数値を算出できます。

Acme Corporationの例に戻り、前項に記述されている要件に基づいて各変数に値を代入します。表20-10は、この項で紹介するAcme Corporationの各変数の値を示したものです。

表20-10 サイズ計算に使用する変数の値

変数名	値
num_entries	1,000,000
attrs_per_entry	20
avg_attr_size	32バイト
avg_dn_size	40バイト
objectclass_per_entry	5（各エントリが平均5つのオブジェクト・クラスに所属）
objectclass_size	10バイト
num_cataloged_attrs	10
entries_per_catalog	1,000,000
change_log_capacity	80,000の変更（ユーザーごとに2つの変更）
num_acis	80,000のACI（ユーザーごとに2つのACI）
num_auditlog_entries	1000
db_storage_ovhd	1.4（40%のオーバーヘッド）
db_index_ovhd	5.0（400%のオーバーヘッド）
factor_of_safety	1.5（50%の安全係数）
initial_num_entries	1,000,000
num_stats_entries	5
attrs_per_stats_entry	12
orclstatsperiodicity	60（ルートDSE属性）
avg_attrname_len	6

これらの値を前述の等式に代入すると、表20-11にリストした値が得られます。

表20-11 表領域のサイズ

表領域名	サイズ（バイト）	サイズ（MB）
OLTS_ATTRSTORE	2,223,000,000	2182
OLTS_CT_STORE	2,328,512,000	274
OLTS_DEFAULT	159,680,000	156
OLTS_SVRMGSTORE	2,701,568	3
SYSTEM	314572800	300
合計サイズ	5038093862	4920

表20-11は、Acme Corporationのデータベースの見積りサイズが約8.25GBであることを示しています。すべてのデータを一括してロードする場合、Oracle Internet Directoryのbulkloadツールには、一時ファイルを格納するためにデータベースが使用する追加領域が30%必要です。Acme Corporationの場合は、領域要件の合計に約2.5GBを追加します。

メモリー要件

メモリーは、Oracle Internet Directoryなどのあらゆるデータベース・アプリケーションが、多数の個別のタスク用に使用します。いずれかのタスクに対するメモリー・リソースが不十分な場合は、CPUの稼働率が低くなり、システム・パフォーマンスが低下します。また、メモリー使用量はデータベースへの同時接続数とディレクトリの同時ユーザー数に比例して増加します。容量計画の目的で、アクティブな接続は、クライアントがディレクトリとのバインドを要求したときに開始し、このバインドが完了したときに終了します。

処理に使用できるメモリーは、システム上の仮想メモリーから供給されます。これは、使用可能な物理メモリーよりもやや大きいメモリーです。全アクティブ・メモリー使用量の合計が、そのシステムで使用可能な物理メモリーを超えると、オペレーティング・システムは、ある程度のメモリー・ページをディスク上に格納する必要があります。この作業をページングと呼びます。使用可能な物理メモリーをはるかに超えるメモリーを使用すると、ページングによってパフォーマンスが低下することがあります。一般的に、物理メモリーの20%を超えたメモリーは使用しないでください。ページングが発生した場合は、プロセスごとのメモリー使用量を減らすか、または物理メモリーを追加する必要があります。ただし、トレードオフに注意してください。追加できるメモリーには物理的な制限があり、プロセスごとのメモリー使用量を減らすとパフォーマンスが大幅に低下します。

メモリーを主に消費するのは、システム・グローバル領域（SGA）内のデータベース・バッファ・キャッシュおよびOIDサーバー・エントリ・キャッシュ（使用可能な場合）です。バッファ・キャッシュおよびエントリ・キャッシュのヒット率を高くするには、各領域に十分なメモリーを割り当てる必要があります。次の計算式は、エントリ・キャッシュ内に'N'個のエントリをキャッシュするために必要なRAMの量の概算を示しています。

N * [ 150+ {attrs_per_entry + 6) * (avg_attrname_len + avg_attr_size + 40) } ]
* 1.3

関連項目
SGAのチューニングの詳細は、第21章「ディレクトリのチューニングに関する考慮事項」を参照してください。

表20-12に、異なるディレクトリ構成別に最小メモリー要件を示します。

表20-12 ディレクトリ構成別最小メモリー要件

ディレクトリのタイプ	エントリ件数	最小メモリー
小	600,000未満	512MB
標準	600,000～2,000,000	1GB
大	2,000,001以上	2GB

Acme Corporationの例では、ディレクトリ内のエントリ数は約1,000,000（100万）です。パフォーマンスを最大にするには、2GBを選択してください。

ネットワーク要件

ほとんどの場合、ネットワークがボトルネックとなることはありません。ただし、容量計画の段階では、慎重に考慮する必要があります。クライアントがOracle Internet Directoryとのメッセージ送受信用に十分なネットワーク帯域幅を確保していない場合は、全体的なスループットが非常に低く感じられます。たとえば、毎秒800の検索を処理するようにOracle Internet Directoryを構成しても、Oracleディレクトリ・サーバーを実行しているコンピュータへのアクセスに使用できるのが10Mbpsのネットワーク（10-Base-Tイーサネット）のみなので、使用可能な帯域幅が60パーセントの場合、クライアントは、スループットが毎秒600検索操作であると理解します（各検索操作で1024バイトがネットワークで移送されると仮定した場合）。表20-13に、2種類の操作（1024バイトの転送を必要とする操作と2048バイトの転送を必要とする操作）について、10Mbpsと100Mbpsの2つのタイプのネットワークで、帯域幅の使用可能率が異なる場合の最大可能スループット（操作/秒）を示します。

表20-13 2種類の操作の最大可能スループット

帯域幅の使用可能率	操作/秒 1024 バイト		操作/秒 2048バイト
帯域幅の使用可能率		10Mbps	100Mbps	10Mbps	100Mbps
30	300	3000	150	1500
40	400	4000	200	2000
50	500	5000	250	2500
60	600	6000	300	3000
70	700	7000	350	3500
80	800	8000	400	4000
90	900	9000	450	4500

場合によっては、クライアントからOracleディレクトリ・サーバーへのメッセージ送信時のネットワーク待機時間を考慮することが重要になります。WANの環境によっては、ネットワーク待機時間が500ミリ秒になる場合があり、操作によっては、クライアントがタイムアウトとなる可能性があります。要約すると、各種ネットワーク・オプションがある場合は、常に帯域幅が最大で、待機時間が最短のネットワークを選択することをお薦めします。

Acme Corporationの例では、ピーク時の使用率は1時間当り936,000参照で、ディレクトリへの参照操作がこの回数実行されます。つまり、毎秒約260のディレクトリ操作が実行される必要があります。各操作で2KBのデータがネットワーク上を転送されると仮定すると、100Mbpsのネットワークを使用するか、または10Mbpsのネットワークで最低60パーセントの帯域幅を使用する必要があります。100Mbpsのネットワークの方が通常待機時間が短いため、10Mbpsのネットワークより優先して選択することになります。

CPU要件

この項では、次の項目について説明します。

CPU構成

Oracle Internet Directoryに関するCPUのサイズ設定は、ユーザーの作業負荷に直接影響を与えます。CPU構成は、次の要因によって決まります。

サポートする同時操作の数。この数は、操作を同時に実行しているユーザー数に直接依存します。
各操作の許容待機時間。たとえば、電子メール・アプリケーションの場合、1操作ごとの待機時間が100ミリ秒であることが理想的ですが、多くの場合、500ミリ秒でも許容範囲内です。

作業負荷の増加に従って、システムにCPUリソースを追加できますが、CPUリソースを追加しても、すべての操作にそのままスケーラビリティがもたらされることはほとんどありません。これは、多くの操作が単にCPUのみに制限されるわけではないためです。このため、すべてのベンダーから一般的に入手可能なパフォーマンス特性（SPECint_rate95ベースライン）によって、コンピュータの処理能力が分類されます。この数値は、一連の整数テストから導き出され、すべてのシステム・ベンダーおよびSPECのWebサイト（http://www.spec.org）から入手可能です。

注意
SPECint_rate95の数値を、通常のSPECint95のパフォーマンス数値と混同しないでください。SPECint95のパフォーマンス数値は、特定のCPUの整数処理能力に関する知識を提供します（CPUが複数あるシステムの場合、この数値は通常正規化されます）。SPECint_rate95は、正規化を実行せずにシステム全体の整数処理能力を提供します。

Oracle Internet Directoryは、SMPコンピュータで複数のCPUを効率的に使用しているため、SPECint_rate95の数値に基づいてコンピュータを分類できます。SPECint_rate95の範囲では、一般的に公表されている結果と異なるベースラインの数値が選択されています。これは、一般的に公表されている結果が、実際にはコンピュータのピーク時のパフォーマンスであるのに対して、ベースラインの数値は、通常の状況下のパフォーマンスを表しているためです。

CPU要件の概算

Oracle Internet Directoryは、通常Oracle Databaseと同じマシンに常駐しているため、少なくとも2CPUのシステムをお薦めします。Oracle Internet Directoryの使用レベルに基づいて、表20-14のように概算で見積もることができます。

表20-14 CPU要件の概算

使用方法	CPUの数	SPECint_rate95ベースライン	システム
部門単位	2	60～200	Compaq AlphaServer 8400 5/300（300MHz×2）
組織単位	4	200～350	IBM RS/6000 J50（200MHz×4）
会社単位	4+	350+	Sun Ultra 450（296 MHz×4）

CPU要件の詳細な計算

CPUの消費量はいくつかの要因によって変化するため、所定の配置サイトですべての操作に対するCPU要件を判断することは困難です。次のような要因があります。

操作の種類（ベース検索、サブツリー検索、変更、追加など）。
SSLモードを使用可能にしているかどうか（SSLを使用すると、15～20%多くCPUリソースが消費されます）。
Oracle Internet Directoryサーバーのエントリ・キャッシュを使用可能にしているかどうか（ヒット率がCPU使用量に影響を与えるため）。
検索で戻されるエントリの数。
検索操作中にチェックする必要があるアクセス制御ポリシーの数。

SSLを除くほとんどの場合、Oracle Internet Directoryサーバー・プロセスとデータベースとの間にかなりの待機時間があることが予想されます。Oracle Internet Directoryサーバー・プロセスのスレッドがデータベースの応答を待機しているときは、Oracle Internet Directoryサーバー・プロセス内のその他のスレッドを、LDAPサーバー固有の処理が必要なその他のクライアント・リクエストの作業に充てることができます。この結果、操作のいかなる組合せでも、同時クライアントとOracle Internet Directoryサーバー・プロセスの組合せが常に実現でき、CPU使用率が100%になります。この場合は、CPUがボトルネックとなります。

この事実を考慮し、メッセージング・タイプのサブツリー検索操作を採用し、操作のスループットを低下させずに、指定された数の同時操作をサポートするために必要なCPUリソースを算出しています。メッセージング検索操作には、サブツリー有効範囲、単純な完全一致フィルタおよび1つのエントリの結果セットが関係します。Oracle Internet Directory 10gリリース2（10.1.2）の場合は、次のようになります。

SPECint_rate95ベースライン= 0.5×（ピーク時のスループットでの同時操作最大数）

これは、操作のスループットを低下させずに、600の同時クライアントをサポートする必要がある場合は、（0.5×600）= 300以上のSPECint_rate95ベースライン評価のコンピュータが必要であることを意味します。

操作のスループットについては、Oracle Internet Directory 10gリリース2（10.1.2）の場合、次のようになります。

SPECint_rate95ベースライン= 0.4×（サポートされる同時操作最大数での操作のスループット）

これは、サポートされる同時操作数として指定した最大数に、毎秒750操作のスループットが必要な場合は、（0.4×750）= 300以上のSPECint_rate95ベースライン評価のコンピュータが必要であることを意味します。

Oracle Internet Directoryは、追加CPUリソースを確実に調整することが証明されています。これは次のことを意味します。

指定した操作同時実行性については、CPUリソースを追加することによって、より高いスループット（待機時間がより短い）の操作を達成できます。
指定した操作スループット（待機時間）については、別途のCPUリソースを追加することによって、より高い操作同時実行性を達成できます。

Acme Corporationの例に戻り、各クライアントにわずかな待機時間を見込みながら、500の同時メッセージング・タイプのサブツリー検索操作をサポートする適切なCPUリソースが必要であると仮定します。安全係数を20%とすると、CPU要件の仮見積りは、360以上のSPECint_rate95ベースラインを持つコンピュータとなります。

Acme Corporationの容量計画のまとめ

ここまでの各項で、容量計画に関係する様々なコンポーネントを説明するとともに、それぞれのコンポーネントを、Acme Corporationという仮想の会社におけるOracle Internet Directoryの配置に適用する方法も紹介しました。この項では、前述のすべての推奨事項を簡単に要約して示します。最初の仮定は次のとおりです。

ディレクトリ全体のサイズ: 3,200,000エントリ（320万）
ユーザー数: 40,000
アプリケーションのタイプ: IMAPメッセージング
ピーク時の検索率: 500クライアントの同時実行性で750検索/秒

この要件とその他の仮定に基づいて、次の推奨事項を提示しました。

ディスク領域: 5GB～8GB
メモリー: 2GB
ネットワーク: 100 Base-T
CPU: SPECint_rate95の数値が360以上のCPU

サイズ設定の計算を直観的に理解できるように、いくつか単純な仮定を使用しました。

20 ディレクトリの容量計画