ワーカースレッドの最大値は、グローバルセクションに設定するthreadsディレクティブで設定可能です。デフォルトでは最大16まで生成され、プールされて管理されます。一般に認証や検索といった参照系の処理が多い場合は、デフォルトの設定のままで問題ありません。しかし、エントリの登録や削除、属性情報の変更といった更新系の処理が多い場合は、threadsディレクティブの設定を64、128などと大きくすると処理性能が向上します。
運用中にslapd.confに指定したワーカースレッドの最大値を確認するには、monitorデータベースを次のように利用します。
# cd /usr/local/openldap-2.4.23 |
また、現時点で生成済みであり、プールされているワーカースレッドの数は、次のように確認します。
# cd /usr/local/openldap-2.4.23 |
さらに、プールされたワーカースレッドのうち、現時点でクライントから要求された処理を実行している最中のスレッドの数は、次のように確認できます。
# cd /usr/local/openldap-2.4.23 |
ここからは、OpenLDAPサーバでの同時接続数の管理と、その確認方法について説明していきます。
LDAPクライアントからOpenLDAPサーバへの同時接続数は、ファイルディスクリプタで管理されています。ファイルディスクリプタとは、プロセスがファイルを開くとき、ネットワーク接続を行う際に利用する管理上の識別子となる情報です。OpenLDAPサーバも、バックエンドデータベースから提供されるファイルを利用したり、LDAPクライアントからのリクエストを受けるたびに、ファイルディスクリプタを消費しています。
このファイルディスクリプタは、1つのプロセスがOSリソースを大量に消費してしまわないよう、デフォルトでは1024に設定されています。OpenLDAPサーバの実体であるslapdプロセスも例外ではなく、デフォルトでは安全よりの設定です。この設定のままでは、OpenLDAPサーバがオープン済みのファイル数を1024から引いた程度の値までしか、LDAPクライアントからの接続を同時に受け入れることができません。
ファイルディスクリプタの制限に引っ掛かったLDAPクライアントは、別のクライアントからの接続が終了し、OpenLDAPサーバ側で利用可能なファイルディスクリプタに空きができるまで、接続を待たされることになります。このような状況は、OpenLDAPサーバのログファイルからも確認できます。以下の出力は、「/var/log/ldap.log」にログを出力している場合の例です。
# less /var/log/ldap.log |
当然ではありますが、接続を待たされたクライアントのレスポンスタイムは悪化します。同時に接続される可能性があるLDAPクライアントが多く存在することが分かっている場合は、このファイルディスクリプタの最大値を、あらかじめ大きく取っておく必要があります。
ファイルディスクリプタ数の制限を緩和するには、「/etc/security/limits.conf」に設定を行うか、またはulimitコマンドを用いて、コマンドを実行したシェルから起動するプロセスに対してのみ有効となる設定が必要です。
# cd /usr/local/openldap-2.4.23 |
運用中にOpenLDAPサーバに許可されたファイルディスクリプタ数の上限を確認するには、次のように/procファイルシステムを利用できます。
# cd /usr/local/openldap-2.4.23 |
また、現時点でOpenLDAPサーバへの接続が確立されているクライアント数、すなわち現時点での同時接続数は、monitorデータベースより確認することができます。
# cd /usr/local/openldap-2.4.23 |
第5回と第6回に分けて、OpenLDAPサーバのパフォーマンスチューニングについて説明しました。第5回では、基本的ではありますが、OpenLDAPサーバのおおむねの性能を決定する大切なチューニング項目を説明しました。
あと一歩というところのパフォーマンスを追究するには、今回説明したような、OpenLDAPサーバを適用するサービスに必要なエントリの数、参照系、更新系処理の割合、または、起こり得る最大同時接続数といったシステムの要件を確認しながらチューニングを行っていくとよいでしょう。
Copyright © ITmedia, Inc. All Rights Reserved.