ビシッと決めるチューニング：もう一絞り編：OpenLDAPによるディレクトリサーバ運用（6）（2/3 ページ）

ユーザー情報や組織情報などを一元的に管理するディレクトリサーバは、企業システムの中で重要な役割を果たしています。オープンソースの「OpenLDAP」によるディレクトリサーバの構築方法を解説した前連載に続き、その運用方法を紹介していきます。（編集部）

[菊池研自，伊藤忠テクノソリューションズ株式会社]

IDリストキャッシュのチューニング

　次に紹介するOpenLDAPサーバのキャッシュ領域は、IDリストキャッシュです。IDリストキャッシュはインデックスキャッシュとも呼ばれ、インデックスファイルから取得したID、またはIDのリストを、OpenLDAPサーバ側でキャッシュする領域です。検索フィルタで指定されたインデックス情報をキーとして取得したIDをこのキャッシュ領域に保存しておくことで、OpenLDAPサーバは2回目以降のインデックスファイルへのアクセスを省略できます。

図2　IDリストキャッシュの役割

　IDリストキャッシュの設定は、エントリキャッシュと同じく、OpenLDAPサーバ全体で行う設定ではなく、バックエンドデータベースがBerkeley DB（bdb）、またはHierarchical DB（hdb）の場合に、それぞれのバックエンドデータベースに対して行う設定です。

　IDリストキャッシュの設定に用いるディレクティブはidlcachesizeであり、デフォルトでは0、つまり、キャッシュをまったく行わない設定となっています。パフォーマンスチューニングの方針としては、1つのエントリにつき1つのIDを持つBerkeley DB（bdb）では全エントリ数と同数を設定し、また1エントリにつき3つのIDを持つHierarchical DB（hdb）では、全エントリ数の3倍の数を確保することが推奨されています。

　実際のIDリストキャッシュの設定は、以下のとおりに行うことができます。

IDリストキャッシュの利用状況

　運用中に、IDリストキャッシュの利用状況を確認するには、以下のようにmonitorデータベースを利用します。次の例では「uid=test1000」という検索フィルタを用いて、上記のslapd.confで指定したインデックスを利用した検索を行った後に、IDリストキャッシュに格納されたIDの数を確認しています。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

DNリストキャッシュの利用状況

　DNキャッシュは、その名のとおり、エントリを識別するDN（Distinguished Name）を、OpenLDAPサーバ側でキャッシュする領域です。この領域は、不足することがないよう、デフォルトの状態で無制限にキャッシュ可能と設定されています。このため、DNキャッシュについては、パフォーマンスチューニングであえてキャッシュサイズの制限を設ける必要はありません。

　DNキャッシュの利用状況は、以下のように確認できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

ワーカースレッドのチューニング

　ここからはOpenLDAPサーバのスレッド処理の概要と、チューニング対象となるワーカースレッドの設定方法および動作状態の確認方法を説明していきます。

　OpenLDAPサーバは、コンフィグレーション実行時に、システム側よりスレッドライブラリが提供されていることが確認できると、マルチコア、またはマルチスレッドのCPUを適切に活用できるよう、マルチスレッドで動作するようにコンパイルされます。

　また、OpenLDAPサーバが生成するスレッドは、

• 「リスナースレッド」と呼ばれるクライアントからのリクエストを受け取るスレッド
• 「ワーカースレッド」と呼ばれるLDAPサーバとしての処理を実現するスレッド

の2つのタイプで構成されています。

図3　リスナースレッドとワーカースレッド

　リスナースレッドは、OpenLDAPサーバの起動時に生成されるスレッドであり、ワーカースレッドは、クライアントからのリクエストを受けてから必要に応じて生成されていくスレッドです。また、ワーカースレッドは生成された後に、プールされて管理されます。

　OpenLDAPサーバはこのスレッドプールを活用することにより、リクエストを受けるたびにスレッドを生成し、処理が終了するたびにスレッドを破棄するのではなく、スレッドを使い回すことで、スレッド生成と破棄のオーバーヘッドを削減できるようになります。