|
| Sun ONE Directory Server インストールおよびチューニングガイド |
Directory Server では、クライアントの要求にすばやく対応できるように、ディレクトリ情報をメモリやディスクにキャッシュします。適切にキャッシュをチューニングすることで、クライアント要求を処理するときにディスクサブシステムにアクセスする必要が最小限になります。
注 キャッシュをチューニングして適切に動作する前に、ほかのチューニングを行なってもパフォーマンスに与える効果は制限される場合があります。
キャッシュのタイプ
Directory Server では、表 6-1 で説明するように 3 タイプのキャッシュを処理します。
Directory Server では、オペレーティングシステムが処理するファイルシステムキャッシュやディスクサブシステムの I/O バッファも有益です。
図 6-1 に 3 つのサフィックスを処理する Directory Server のキャッシュを示します。それぞれのサフィックスには専用のエントリキャッシュがあります。インスタンスは重要なディスクのアクティビティを処理するように設定されており、トランザクションログ、データベース、ほかのファイルやログなどは第 8 章「ログのチューニング」で推奨するように、別のディスクサブシステムに配置されています。
図 6-1 コンテキストにおけるエントリキャッシュとデータベースキャッシュ
データベースキャッシュ
各 Directory Server インスタンスにはデータベースキャッシュが 1 つあります。データベースキャッシュはインデックスやエントリを含むデータベースからのページを保持します。ページはエントリではなく、データベースの一部が含まれるメモリの断片です。データベースキャッシュのサイズはユーザーが指定します (nsslapd-dbcachesize)。データベースキャッシュのサイズ変更は、サーバーの再起動後、サーバーの起動時に割り当てられるデータベースキャッシュ領域で有効になります。
Directory Server はデータベースファイルとデータベースキャッシュとの間でページを移動し、データベースキャッシュのサイズが最大になるように維持します。Directory Server によってデータベースキャッシュ用として実際に使用されるメモリの量は、指定したサイズよりも最大で 25% 大きくなることがあります。これはデータベースキャッシュ自体を管理するのに追加のメモリが必要となるためです。
非常に大きなデータベースキャッシュを使用する場合、経験テストを実施したり、Solaris システム上の pmap(1) などのツールを使ってメモリ使用量を監視したりして、Directory Server によるメモリ使用量が利用可能な物理メモリのサイズを超えないかどうかを検証します。利用可能な物理メモリを超えると、システムがページングを繰り返し行うようになり、深刻なパフォーマンスの低下を招きます。
また、Directory Server がサポートする UNIX プラットフォーム上に存在する ps(1) ユーティリティで -p pid オプションと -o format オプションを指定しても、Directory Server (ns-slapd) などといった特定のプロセスによる現在のメモリ使用量を表示することができます。Windows システムの場合、「タスク マネージャ」の「プロセス」タブページに、各プロセス (slapd.exe など) のメモリ使用量が一覧表示されます。詳細は、オペレーティングシステムのマニュアルを参照してください。
32 ビットサーバーの場合、データベースキャッシュのサイズは実際には 2G バイト以下にする必要があります。
注 Windows や AIX プラットフォームでは、1G バイト (1,073,741,824 バイト) 以上をデータベースキャッシュに割り当てないでください。
nsslapd-dbcachesize の有効な値の範囲についての詳細は、『Sun ONE Directory Server Reference Manual』を参照してください。
エントリキャッシュ
エントリキャッシュには、最近アクセスしたエントリが、クライアントアプリケーションに配信できる形式で保持されます。サフィックス (nsslapd-cachememsize) と最大エントリ数 (nsslapd-cachesize) のキャッシュサイズはユーザーが指定します。エントリキャッシュは必要に応じて割り当てられます。
Directory Server では、このキャッシュに格納されたエントリはフォーマットされているので、最大限に効率的にエントリキャッシュからエントリを戻すことができます。データベース内のエントリは、バイトの raw 文字列として格納されますが、クライアントアプリケーションに配信される前に形式化してエントリキャッシュに格納される必要があります。
エントリキャッシュのサイズを指定するときに、nsslapd-cachememsize には、基盤となる記憶域割り当てライブラリに Directory Server が要求するメモリー量を指定します。記憶域割り当てライブラリが処理するメモリー要求の量によっては、実際に使用されるメモリー量は、Directory Server がエントリキャッシュに実際に割り当てるメモリー量よりもかなり大きくなります。
Directory Server プロセスが使用する実際のメモリー量は、主として、使用される記憶域割り当てライブラリとキャッシュされるエントリ数によって決まります。多数の小さな属性値を持つエントリは、少数の大きな属性値を持つエントリよりも、通常は負荷が大きくなります。
32 ビットサーバーの場合、エントリキャッシュのサイズは実際には 2G バイト以下にする必要があります。
注 AIX プラットフォームでは、Directory Server が maxdata = 0x50000000 で作成されるため、データベースキャッシュとエントリキャッシュの両方に 1G バイトずつ割り当てることができます。maxdata の値を変更する必要がある場合は、ご購入先までお問い合わせください。
nsslapd-cachememsize と nsslapd-cachesize の有効な値の範囲についての詳細は、『Sun ONE Directory Server Reference Manual』を参照してください。
インポートキャッシュ
インポートキャッシュは、サフィックスの初期化中にだけ作成されて使用されます。サフィックスの初期化のことを一括ロードまたはインポートとも言います。導入時にオフラインのサフィックス初期化だけが行われる場合は、インポートキャッシュとデータベースキャッシュが同時に使用されることはありません。そのため、「総計キャッシュサイズ」で説明しているように、キャッシュサイズをまとめるときに、インポートキャッシュとデータベースキャッシュを足し合わせる必要はありません。インポートキャッシュのサイズはユーザーが指定します (nsslapd-import-cachesize)。インポートキャッシュのサイズ変更は、次にサフィックスをリセットして初期化したときに有効になります。インポートキャッシュは初期化で割り当てられ、初期化後に解放されます。
Directory Server ではインポートキャッシュの処理をデータベースキャッシュの処理と同じように行います。そのため、スワップを避けるために、十分な物理メモリが利用できることを確認してください。
32 ビットサーバーの場合、インポートキャッシュのサイズを実際には 2G バイト以下にする必要があります。nsslapd-import-cachesize の有効な値の範囲についての詳細は、『Sun ONE Directory Server Reference Manual』を参照してください。
ファイルシステムキャッシュ
オペレーティングシステムでは、Directory Server キャッシュやほかのアプリケーションで使用しない利用可能なメモリをファイルシステムキャッシュに割り当てます。このキャッシュにはディスクから最近読み込んだデータを保持しているため、後続の要求ではディスクからもう一度読み込むのではなく、コピーされたデータをキャッシュから取得することができます。メモリアクセスはディスクアクセスより高速なので、物理メモリをファイルシステムキャッシュに利用できるようにしておくことで、パフォーマンスが向上します。
ファイルシステムキャッシュについての詳細は、オペレーティングシステムのマニュアルを参照してください。
総計キャッシュサイズ
同時に使用されるすべてのキャッシュの合計が、利用可能な物理メモリの合計サイズ未満となる必要があるため、ファイルシステムキャッシュに割り当てるメモリは少なく設定します。32 ビットサーバーの場合、総計キャッシュのサイズは実際には 2G バイト以下に制限されます。使用されるキャッシュの合計が、ユーザーが指定したサイズを大幅に上回る可能性があります。キャッシュサイズと Directory Server プロセスサイズが、利用可能な物理メモリのサイズを超えていないかどうかをチェックする方法については、 「データベースキャッシュ」を参照してください。
注 Windows プラットフォームで、アプリケーションが使用可能な最大アドレス空間は 2G バイトです。総計キャッシュサイズがこの制限を超えると、Directory Server はエラーメッセージを表示して終了します。
Directory Server がオンラインのときにサフィックスが初期化 (一括ロード) される場合は、データベース、エントリ、インポートの各キャッシュサイズの合計が、利用可能な物理メモリの合計サイズよりも小さく設定される必要があります。
表 6-2 サフィックスの初期化 (インポート) 操作とキャッシュの使用
キャッシュのタイプ
オフラインインポート
オンラインインポート
データベース
未使用
使用
エントリ
使用
使用
インポート
使用
使用
Directory Server の停止中にすべてのサフィックス初期化がオフラインで行われる場合は、この制限を回避することができる場合があります。この場合、インポートキャッシュはデータベースキャッシュと共存しないため、同じメモリをオフラインのサフィックス初期化ではインポートキャッシュに割り当て、オンラインでの使用にはデータベースキャッシュに割り当てることができます。このような特殊な場合の実装では、実際の運用システムでオンライン一括ロードを実行しないようにしてください。同時に使用するキャッシュの合計は、利用可能な物理メモリの合計サイズ未満であることが必要です。
検索でキャッシュを使用する方法
図 6-2 に Directory Server がベース DN を使用した検索と、フィルタを使用した検索の両方を処理する方法を示します。それぞれの線は、メモリの異なるレベルにアクセスするスレッドを表しています。破線は、効率的なチューニングによって最小化されるステップを表します。
図 6-2 検索とキャッシュ
ベース検索のプロセス
図で示すように、ベース検索、つまりベース DN を指定する検索は、Directory Server が処理する検索のうち、もっともシンプルなタイプです。この検索を行うために、Directory Server では次を行います。
- 指定したベース DN を持つエントリをエントリキャッシュから取得しようとします。
ここで、エントリが見つかった場合、Directory Server は検索用に指定したフィルタとその候補が一致するかどうかをチェックします。
エントリが一致する場合は、Directory Server によって、形式化されキャッシュされたエントリがクライアントアプリケーションにすばやく返されます。
- エントリをデータベースキャッシュから取得しようとします。
ここで、エントリが見つかった場合、Directory Server はそのサフィックス用のエントリキャッシュにエントリをコピーします。次に、エントリがエントリキャッシュで見つかったときと同様の処理をします。
- エントリをデータベース自体から取得しようとします。
ここで、エントリが見つかった場合、Directory Server はデータベースキャッシュにエントリをコピーします。次に、エントリがデータベースキャッシュで見つかったときと同様の処理をします。
サブツリーまたは 1 レベルの検索処理
また図 6-2 に示すように、サブツリーや 1 レベルの検索では、エントリのセットを処理するのに追加の処理が行われます。この検索を行うために、Directory Server は次の処理を行います。
- フィルタに一致する候補エントリのセットを、データベースキャッシュのインデックスから作成しようとします。
適切なインデックスが見つからない場合は、データベース自体にある関連エントリから候補エントリのセットが作成されます。
- 各候補エントリは、次のように処理されます。
- ベース検索を実行してエントリを取得します。
- 検索で指定したフィルタとエントリが一致するかどうかチェックします。
- エントリがフィルタに一致する場合は、クライアントアプリケーションに返されます。
この方法で、Directory Server は、メモリにセットを構成することを回避します。
Directory Server をチューニングする前に、期待する検索内容を知っておくことが理想的ですが、実際にテストを行なって仮定した内容を検証してください。
更新でキャッシュを使用する方法
図 6-3 に、Directory Server で更新を処理する方法を示します。それぞれの線は、メモリの異なるレベルにアクセスするスレッドを表しています。破線は、効率的なチューニングによって最小化されるステップを表します。
図 6-3 更新とキャッシュ
更新では検索の場合よりも多くの処理が行われます。Directory Serverは、次の手順で更新を実行します。
- ベース DN 検索を実行して、更新するエントリを取得します。追加操作の場合は、エントリがまだ存在していないことを確認します。
- データベースキャッシュを変更し、特に、更新の影響を受けるあらゆるインデックスを更新します。
更新の影響を受けるデータがデータベースキャッシュにロードされていない場合、このステップはディスクアクティビティとなります。関連データはキャッシュに読み込まれます。
- トランザクションログに変更内容についての情報を書き込み、情報がディスクにフラッシュされるまで待機します。
詳細は、「トランザクションログ」を参照してください。
- 更新されたエントリを形式化し、そのサフィックスのエントリキャッシュにコピーします。
- 更新に成功した通知をクライアントアプリケーションに返します。
サフィックスの初期化でキャッシュを使用する方法
図 6-4 に、Directory Server でサフィックスの初期化を処理する方法を示します。サフィックスの初期化は一括ロードインポートとも呼ばれます。それぞれの線は、メモリの異なるレベルにアクセスするスレッドを表しています。破線は、効率的なチューニングによって最小化されるステップを表します。
図 6-4 サフィックスの初期化 (一括ロード) とキャッシュ
Directory Serverは、次の手順でサフィックスを初期化します。
- LDIF からデータをバッファとして使用するエントリキャッシュに与えるスレッドを起動します。
- 影響を受ける各インデックス用のスレッドと、インポートキャッシュにエントリを作成するスレッドを起動します。これらのスレッドは、エントリキャッシュに入れられたエントリを使用します。
- インポートキャッシュを使い切った場合、データベースファイルの読み書きを行います。
Directory Server ではサフィックスの初期化中にログメッセージの書き出しを行うこともありますが、トランザクションログには書き出しません。
Directory Server に同梱されている ldif2db (/usr/sbin/directoryserver ldif2db) などのサフィックス初期化ツールでは、キャッシュのヒット率やインポートのスループットに関するフィードバックがあります。キャッシュのヒット率とインポートのスループットの両方が低下するということは、インポートキャッシュが小さすぎる可能性があるということです。インポートキャッシュのサイズを増やすことを検討してください。
検索の最適化
最高のパフォーマンスを得るために、できるだけ多くのディレクトリデータをメモリにキャッシュしてください。ディレクトリがディスクから情報を読み込まないように、ディスクの I/O ボトルネックを制限します。さまざまな方法で行うことができますが、ディレクトリツリーのサイズ、利用可能なメモリ量、使用しているハードウェアなどによって変わります。導入によっては、エントリキャッシュやデータベースキャッシュに割り当てるメモリを多くしたり少なくしたりして、検索パフォーマンスを最適化します。また、複数のサーバーの Directory Server コンシューマに検索を配布すると、検索パフォーマンスが最適化されます。
メモリにすべてのエントリとインデックスがある場合
最適な場合を考えてみます。データベースキャッシュとエントリキャッシュの合計サイズは、利用可能な物理メモリの範囲内です。エントリキャッシュは、ディレクトリのエントリすべてを保持できるサイズです。データベースキャッシュは、少なくともインデックスすべてを保持できるサイズです。この場合は、検索するとすべてがキャッシュで見つかります。Directory Server はファイルシステムキャッシュやディスクからエントリを取得する必要はありません。
従って、更新後でもデータベースキャッシュには必ずすべてのデータベースインデックスが含まれています。データベースキャッシュでインデックス用の空きがなくなった場合、Directory Server では検索要求ごとにディスクからインデックスを読み込む必要があり、スループットに深刻な影響を与えます。図 6-5 に示すように、Directory Server コンソール では「状態」タブにヒット率やほかの有益な情報が表示されます。
図 6-5 Directory Server コンソールを使用したキャッシュヒット率の監視
代わりに次のようにコマンド行から検索を利用して、ページングとキャッシュの状態を監視することもできます。
$ ldapsearch -D admin -w password ¥
-b cn=monitor,cn=database_name,cn=ldbm database,cn=plugins,cn=config.db3 ファイルのすべてのデータベースインデックスをデータベースキャッシュに収めるために必要なメモリ量を概算するには、次の式を使用します。写真のような大きなバイナリ属性を持たない典型的なエントリを使用した、デフォルトのインデックス設定では、この式はほぼ正確です。
nsslapd-dbcachesize = 1.2 x SUMすべての .db3 ファイル(ファイルサイズ)
すべてのエントリをエントリキャッシュに収めるために必要となるエントリキャッシュのスロット数とメモリ量を概算するには、次の公式を使用します。写真のような大きなバイナリ属性を持たない典型的なエントリを使用した、デフォルトのインデックス設定では、この公式はほぼ正確です。
nsslapd-cachesize = 4.5 x (LDIF 内のエントリ数)
nsslapd-cachememsize = 3.8 x (id2entry.db3 のファイルサイズ)
テスト経験を通じて、見積もりを検証し、訂正してください。特に、エントリキャッシュは、割り当てられた量以上のメモリを使用する可能性があります。
32 ビット Directory Server で十分なメモリを確保する場合
ここでは、エントリキャッシュとデータベースキャッシュ内のすべてのデータを格納するのに十分なメモリを搭載しているが、64 ビット Directory Server プロセスをサポートしないシステムを考えてみます。たとえば、ハードウェア上の制約により Solaris システム上に導入できない場合に、32 ビットプロセスのメモリ制限に見合う適切なキャッシュサイズを決めた後、残りの利用可能なメモリをファイルシステムキャッシュ用として残しておくことが大切です。
注 ファイルシステムキャッシュは、システム上のほかのプロセスと共有されます。ファイルベースの操作を行う場合は特にそうです。したがって、ファイルシステムキャッシュの管理は、ほかのキャッシュの場合よりも困難になります。特に、Directory Server 専用でないシステム上では困難です。
システムは、ファイルシステムキャッシュをほかのプロセスに割り当て直す可能性があります。
メモリは少ないがファイルシステムキャッシュはある場合
エントリキャッシュとデータベースキャッシュにすべてのデータを保持するには利用可能なメモリが十分ではないが、それでも多くの利用可能なメモリがあるシステムを考えてみます。この場合の重要な点は、エントリキャッシュとデータベースキャッシュの合計サイズが、利用可能な物理メモリを超えないことです。合計サイズが物理メモリを超えると、仮想メモリの頻繁なページングが発生し、システムの仮想停止が引き起こされる可能性があります。
利用可能なメモリはファイルシステムキャッシュで使用し、エントリキャッシュとデータベースキャッシュのサイズは 500K バイト程度のサイズに抑えます。こうすることで、Directory Server でディスクからエントリやインデックスを繰り返して読み込む必要が生じる前に、検索をファイルシステムキャッシュで完結するのに十分なデータを、ファイルシステムキャッシュに保持することができます。
代わりに、特定の導入におけるほとんどの検索ではディレクトリにある全エントリの同一の小さなサブセットがアクセスされることや、そのような検索のためにエントリやインデックスをキャッシュしたことによる利点が時折発生する特殊な検索要求を処理するためのコストを補ってくれるものと仮定すると、検索パターンがランダムでなければ、エントリキャッシュやデータベースキャッシュを多めに設定することもできます。テスト経験を通じて、仮定を検証し、訂正してください。
メモリが少なく、ファイルシステムキャッシュも少ない場合
エントリキャッシュにもデータベースキャッシュにもデータを保持するための利用可能なメモリが不足しており、システムがファイルシステムキャッシュにデータをキャッシュするにもメモリが不足しているシステムを考えてみます。この場合に重要な点は、利用可能なメモリ量を最大にすることです。
エントリキャッシュとデータベースキャッシュのサイズをできるだけ小さくし、ファイルシステムキャッシュにできるだけ多くのメモリを残します。ファイルシステムキャッシュにできるだけ多くのメモリを残しておくことで、少なくとも 3 〜 4.5 のエントリをデータベースキャッシュやエントリキャッシュに展開する必要がなくなり、論理的にディスク I/O アクティビティを制限することができます。特定の導入において、テスト経験を通じて仮定した内容を検証します。
更新用の最適化
最高の更新パフォーマンスを得るには、まず監視用のトランザクションログのボトルネックを取り除きます。詳細は、「トランザクションログ」を参照してください。
次に、更新をメモリで処理してディスクアクティビティを最小化するのに十分なメモリ量をデータベースキャッシュに割り当ててみます。Directory Server コンソールに表示されるヒット率を読み取ることで、データベースキャッシュの効率性を監視することができます。図 6-5 に示すように、Directory Server コンソールでは「状態」タブにサフィックスのヒット率が表示されます。
同様に、ファイルシステムキャッシュに利用できるメモリを大きめに残すようにします。Directory Server が数回処理を行なったら、ファイルシステムキャッシュにはディスクを読み込まずに済むだけの十分なエントリとインデックスが格納されているはずです。更新ではメモリ内のデータベースキャッシュに影響を与え、大きいデータベースキャッシュからのデータはフラッシュされることがあります。
データをディスクにフラッシュすること自体もボトルネックであるため、Sun StorEdgeTM ディスクアレイのような別の RAID システムにデータベースを格納することで、更新パフォーマンスが改善されます。潜在的な I/O ボトルネックを分離するには、Solaris システムの iostat (1M) などのユーティリティを使用することもできます。Windows システムの I/O ボトルネックへの対応方法の詳細は、Windows ヘルプを参照してください。
キャッシュのプライムと監視
キャッシュのプライムとは、後続の Directory Server の動作が、通常の操作パフォーマンスに反映されるようにキャッシュにデータを取り入れることです。潜在的な最適化を測定し分析する前にキャッシュのプライムを行います。
サフィックスのエントリキャッシュのプライムを行うには ldapsearch ユーティリティを使用します。たとえば、次のようにします。
$ ldapsearch -D directoryManager -w password -b suffix objectclass=¥* > /dev/null
検索を実行してデータベースキャッシュのプライムを行い、実際にインデックスをキャッシュにロードします。(mail=*) などのフィルタを使用して検索を実行することで、現在のインデックスのプライムを行えます。ほかのインデックスの場合は、Sun ONE Directory Server Resource Kit の searchrate ユーティリティを使用して、インデックス化するために、各属性の考えられるすべての値を検索するのにフィルタ形式を適用することを検討します。言い換えると、たとえば mail 属性に対する同等の検索のパフォーマンスをチェックするには、各メールアドレスについて 1 行に 1 メールアドレスという形式のファイルを作成します。次に searchrate ユーティリティを使用して、このファイルを使用した検索を実行します。たとえば、次のようにします。
$ searchrate -b suffix -f "(mail=%s)" -i mail.file -K -t 10
-K および -t を使用して時間を節約することを検討してください。-K オプションを使用すると、searchrate では接続を開いたままにして、検索のたびにバインドするのではなく、1 度だけバインドします。-t オプションでは、使用するスレッド数を指定できます。searchrate ユーティリティの詳細は、Sun ONE Directory Server Resource Kit マニュアルを参照してください。Sun ONE Directory Server Resource Kit は、「Directory Server ツールのダウンロード」で説明する手順に従って、取得できます。
ほかのキャッシュがプライムされた後は、利用可能なファイルシステムのキャッシュのプライムを行えます。ファイルシステムキャッシュ内の情報が絶対にフラッシュされないという保証はありませんが、ファイルシステムキャッシュのプライムにより、増加時間が改善される可能性があります。UNIX システム上でファイルシステムのキャッシュのプライムを行うには、dd(1M) コマンドをスーパーユーザーとして使用します。データベースファイルがデフォルトの場所に格納されている Solaris システム上における例を、次に示します。
# for db in ServerRoot/slapd-serverID/db/*/*.db3
> do
> dd if=廃wd��$db of=/dev/null bs=512k
> done
0+1 records in
0+1 records out
...キャッシュのプライムを行なったら、テストを実行し、キャッシュのチューニングによって望ましい結果が得られるかを監視します。図 6-5 に示すように、Directory Server コンソールでは「状態」タブの「サフィックス」ノードを選択すると、キャッシュの監視情報が表示されます。代わりに次のようにコマンド行から検索を利用して、ページングとキャッシュアクティビティを監視することもできます。
$ ldapsearch -D admin -w password ¥
-b cn=monitor,cn=database_name,cn=ldbm¥ database,cn=plugins,cn=configデータベースキャッシュのサイズが十分に大きく、またキャッシュのプライムが行われている場合は、ヒット率 (dbcachehitratio) は高く、読み込まれたページ数 (dbcachepagein) と書き出されたページ数 (dbcacheroevict) は少なくなります。ヒット率の高低を分析するときには、導入の制限も考慮する必要があります。
サフィックスのエントリキャッシュが十分大きく、またキャッシュのプライムが行われている場合、ヒット率 (entrycachehitratio) は高くなります。エントリキャッシュのサイズ (currententrycachesize) は最大サイズ (maxentrycachesize) の 80% を超えないようにします。結果として、エントリのサイズ (currententrycachecount) は、サフィックス内のエントリの総数と等しいか非常に近い値になります。
その他の最適化
キャッシュサイズのチューニングは、検索、更新、一括ロードの速度を改善する単なる 1 つの方法です。キャッシュをチューニングすると、パフォーマンスのボトルネックが、キャッシュからシステムの別の部分へと移ります。詳細は、このマニュアルの別の章を参照してください。