test

Sun Java System Calendar Server 6 2005Q4 管理ガイド

第 21 章 Calendar Server のパフォーマンスの調整

Calendar Server のパフォーマンスを向上させるには、次のオプション設定を検討します。

LDAP ディレクトリサーバーのインデックス設定

Calendar Server が LDAP ディレクトリサーバーにアクセスするときのパフォーマンスを向上させるには、LDAP 設定ファイルの次の属性にインデックスを追加します。

icsCalendar

この属性は、カレンダユーザーまたはリソースのデフォルトカレンダの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。

icsCalendarOwned

この属性は、ユーザーが所有しているほかのカレンダの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。「DWP 環境でのカレンダ検索のパフォーマンス向上」も参照してください。

mail、mailAlternateAddress

これらの属性は、ユーザーの一次電子メールアドレスと代替電子メールアドレスを指定します。「ユーザーとリソースの作成」および 「Calendar Server ユーティリティー (csuser enable)」も参照してください。

ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。

http://docs.sun.com/coll/1316.1

DWP 環境でのカレンダ検索のパフォーマンス向上

DWP 環境にある場合、つまり、複数のバックエンドサーバーにカレンダベースが分散している場合、カレンダデータベース内のカレンダの検索に非常に時間がかかる場合があります。最初に LDAP エントリを探し、カレンダが存在している DWP ホストで直接検索すると、時間を短縮できます。

ここで説明する内容は次のとおりです。

ProcedureLDAP を対象とするカレンダ検索を有効にするには

最初に LDAP ディレクトリ、次にカレンダデータベースを対象とするカレンダ検索を有効にするには、次の手順を実行します。

手順

  1. ics.conf ファイルの service.calendarsearch.ldap パラメータを編集し、そのパラメータを次のようにデフォルトの “yes” に設定します。

    service.calendarsearch.ldap="yes"

  2. 次のようにカレンダサービスを再起動します。

    start-cal

    注 –

    公開カレンダへの匿名アクセスを許可している場合は、LDAP を対象とするカレンダ検索を無効にすることもできます。実際に、Communications Express では、パラメータ値を “no” に設定することをお勧めします。

Procedureインデックスを作成して検索のパフォーマンスを向上させるには

手順

  1. インデックスを作成することにより、カレンダ検索のパフォーマンスを向上させることができるかどうかを調べるには、次の LDAP コマンドを実行します。


    ldapsearch -b "base" "(&(icscalendarowned=*user*)
   (objectclass=icsCalendarUser))"

    ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーが検索ダイアログで入力できる値です。

    60,000 のエントリを使ったテストでは、icsCalendarOwned のインデックスを設定しない場合、前述した検索に要した時間は 50 〜 55 秒でした。インデックスの設定後に検索に要した時間は、約 1 〜 2 秒でした。

  2. comm_dssetup.pl を実行して、適切な LDAP 属性に、または少なくとも icsCalendarOwned にインデックスを設定します。

    comm_dssetup.pl は、この属性やその他の多くの属性にインデックスを設定して、さまざまな方法でパフォーマンスを向上させます。comm_dssetup.pl を実行していない場合、または実行したがインデックス設定を行わなかった場合、ユーティリティーを再実行してインデックス設定を行うか、または Directory Server ツールを使用してインデックスを設定できます。

    comm_dssetup.pl によるインデックス設定については、「属性のインデックス」を参照してください。

    ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。

    http://docs.sun.com/coll/1316.1

ワイルドカード検索の無効化によるカレンダ検索のパフォーマンスの向上

デフォルトでは、Calendar Server でのワイルドカード検索は無効になっています。つまり、グラフィカルユーザーインタフェース (GUI) を使用してカレンダを検索するとき、または、カスタムインタフェースで search_calprops.wcap を実行するときは、WCAP コマンドを使用して渡される検索文字列との完全一致を検索します。

ics.conf ファイルで次の行のコメントを外して (行頭の感嘆符 (“!”) を削除して) ワイルドカード検索を有効にしている場合は、パフォーマンスにマイナスの影響を与える可能性があります。

!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"

パフォーマンスに与えるワイルドカードの影響を調べるには、行の先頭に感嘆符 (“!”) を挿入して行をもう一度コメントアウトします。

CLD プラグインのパフォーマンスの向上

カレンダデータベースからカレンダにアクセスする前に、ユーザーのカレンダをどのバックエンドマシンに格納するかを決める必要があります。適切なバックエンドマシンを見つけるために、システムではユーザーエントリの LDAP ディレクトリを検索し、icsDWPHost 属性を取り出します。この検索は非常に時間がかかり、カレンダデータにアクセスするたびに実行する必要があります。すべてのユーザーセッションでは、データベースのアクセスが多数発生し、LDAP の検索も多くなります。時間を節約してパフォーマンスを向上させるには、次のように ics.conf ファイルを編集して CLD キャッシュを有効にします。

caldb.cld.cache.enable="yes"

LDAP データキャッシュは、ユーザー ID およびそれに関連する icsDWPHost 属性を格納します。LDAP でユーザーのエントリを検索する前に、システムは、キャッシュにそのユーザーの ID がないかどうかチェックします。キャッシュにユーザー ID があれば、そこに格納されている icsDWPHost 属性からバックエンドのホスト名を取り出します。キャッシュにユーザー ID がない場合、システムは LDAP 検索を実行して、ユーザー ID と属性を CLD キャッシュにコピーします。このあとは、キャッシュでユーザー ID が見つかるため、ユーザーのカレンダデータへのアクセスが速くなります。

LDAP データキャッシュのパフォーマンスの向上

LDAP データキャッシュが有効になっている場合は、ics.conf パラメータを使用してキャッシュを調整できます。それには、次の表に示すパラメータを 1 つ以上調整します。

注 –

デフォルトでは、LDAP データキャッシュが有効になっています。LDAP データキャッシュを無効にするには、次のように設定します。local.ldap.cache.enable="no"

表 21–1 LDAP データキャッシュのカスタマイズに使用される ics.conf パラメータ

パラメータ 

説明と値 

local.ldap.cache

.checkpointinterval

チェックポイント間でチェックポイントスレッドがスリープするまでの秒数。デフォルトは “60” です。

高アクティビティーの LDAP では、キャッシュをできるだけ最新のものにしておくため、間隔を短くすることをお勧めします。同時に、キャッシュの更新が頻繁になるほど、システムのオーバーヘッドが高くなることにも留意してください。 

local.ldap.cache.

circularlogging

処理が完了したあとに LDAP データキャッシュのデータベースログファイルを削除するかどうかを指定します。デフォルトは “yes” です。

古いログファイルを削除するカスタムのクリーンアップルーチンがある場合を除いて、このパラメータは変更しないでください。 

local.ldap.cache.

logfilesizemb

チェックポイントファイルの最大サイズを M バイト単位で指定します。デフォルトは "10”M バイトです。

高アクティビティーの LDAP の場合、チェックポイント間隔が終わる前にこのファイルがいっぱいになる可能性があります。経験に基づいて、できるだけログの実サイズに近い値を設定します。 

local.ldap.cache.

maxthreads

LDAP データキャッシュデータベースの最大スレッド数を指定します。デフォルトは “1000” です。

高アクティビテーの LDAP では、スレッド数を増やすことをお勧めします。そうすることにより CPU の使用率が高くなります。LDAP アクティビティーが最小の場合にのみ、スレッド数を減らします。 

local.ldap.cache.

mempoolsizemb

共有メモリーのサイズを M バイト単位で指定します。デフォルトは “4”M バイトです。

local.ldap.cache.

entryttl

LDAP データキャッシュエントリの存続時間 (TTL) を秒単位で指定します。デフォルトは “3600” 秒 (1 時間) です。

キャッシュがあまりにも早くいっぱいになる場合は (高アクティビティー)、TTL 時間を減らします。ただし、これにより全体の LDAP データベースのアクセス数が増加し、全体的にシステムを低下させる可能性があります。 

local.ldap.cache.

cleanup.interval

キャッシュデータベースのクリーンアップの間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

システムにより有効期限が切れたエントリが削除されます。時間間隔は、エントリの TTL 時間と同一である必要はありません。ただし、同期させるとより効率的になります。 

local.ldap.cache.

stat.enable

LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です。

パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。 

local.ldap.cache.

stat.interval

統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

これは、local.ldap.cache.stat.enable が有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。 

注 –

Communications Express では、データキャッシュを無効にすることをお勧めします。

LDAP SDK キャッシュの調整

項目をキャッシュしておく時間、およびキャッシュのサイズを制御するいくつかのパラメータがあります。

キャッシュを調整するには、次の表に示すパラメータを 1 つ以上編集します。

表 21–2 LDAP SDK キャッシュを設定するための ics.conf パラメータ

パラメータ 

説明とデフォルト値 

service.ldapmemcachettl

このパラメータは現在実装されていません。ldap_cache ディレクトリの内容を手動で削除してから、Calendar Server を再起動する必要があります。

service.ldapmemcache に "yes" を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。“0” を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは “30” です。

service.ldapmemcachesize

service.ldapmemcache に "yes" を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリーの最大容量をバイト単位で設定します。“0” を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは “131072” です。

自動バックアップの調整

ディスクに保存するバックアップ数と必要性とのバランスを取って、使用可能なディスク容量を越えないようにする必要があります。アーカイブとホットバックアップに必要なディスク容量を管理するために、さまざまな ics.conf パラメータの設定を変更できます。これらのパラメータにより、一度に保存するバックアップのコピー数、および古いコピーのクリーンアップを行うディスク容量のしきい値が決定されます。

アーカイブ、およびホットバックアップのそれぞれバックアップタイプ用に調整できる次の 3 種類のパラメータがあります。

Calendar Server では、ディスク容量のしきい値を超えずに可能な最大日数の間、バックアップを保持します。そのため、現在のバックアップでディスク使用率がしきい値を超える場合、システムは古いバックアップコピーを破棄し、ディスク容量の使用率がしきい値より低くなるかどうかを確認します。システムは、別のバックアップコピーを削除することにより、ディスク上のバックアップ数が最小バックアップコピー数を下回るか、ディスク容量の使用率がしきい値を下回るまで、古いバックアップコピーを破棄し続けます。

その結果、しきい値のパラメータによりディスク容量のバックアップ使用を管理できます。また反対に、許容されるディスク容量やコピーを調整することにより、ディスクで保持するバックアップ量を管理できます。

次の表は、ディスク容量とディスクに保持されるバックアップ数を制御する ics.conf パラメータを一覧表示しています。

表 21–3 ディスク上に保持するバックアップ数の設定に使用される ics.conf パラメータ

ics.conf パラメータ 

デフォルトの設定 

説明 

caldb.berkeleydb.hotbackup.mindays

3 

ディスク上に保持するホットバックアップの最小日数です。 

caldb.berkeleydb.hotbackup.maxdays

6 

ディスク上に保持するホットバックアップの最大日数です。 

caldb.berkeleydb.hotbackup.threshold

70 

ホットバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。 

caldb.berkeleydb.archive.mindays

3 

ディスク上に保持するアーカイブバックアップの最小日数です。 

caldb.berkeleydb.archive.maxdays

6 

ディスク上に保持するアーカイブバックアップの最大日数です。 

caldb.berkeleydb.archive.threshold

70 

アーカイブバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。 

複数 CPU 間でのロードバランスの使用

サーバーに複数の CPU が実装されている場合、デフォルトでは、Calendar Server は HTTP サービス (cshttpd プロセス) と分散データベースサービス (csdwpd プロセス) を複数の CPU に分散します。

各サービスを実際に実行するプロセッサの数は、service.http.numprocesses および service.dwp.numprocesses パラメータによって決定されます。デフォルトでは、これらのパラメータはインストール時にサーバーの CPU 数に設定されますが、この値を設定し直すことができます。たとえば、サーバーに 8 つの CPU がある場合に、cshttpd および csdwpd プロセスを 4 つの CPU だけで実行するときは、これらのパラメータを次のように設定します。

service.http.numprocesses="4"
 service.dwp.numprocesses="4"

ロードバランスを無効にするには、ics.conf ファイルに service.loadbalancing パラメータを追加し、その値を “no” に指定します。次に、Calendar Server を再起動して変更を適用します。

タイムアウト値の使用

Calendar Server のパフォーマンスは、さまざまな ics.conf パラメータのタイムアウト値を使用して調整できます。

次のタイプのタイムアウトが存在します。

ics.conf パラメータの編集については、「ics.conf 設定ファイルの編集」を参照してください。

csadmind のタイムアウト値

次の表は、管理サービス (csadmind) が使用する、ics.conf ファイル内の Calendar Server タイムアウトパラメータを示しています。

表 21–4 管理サービス (csadmind) の HTTP タイムアウト値

パラメータ 

説明 

service.admin.idletimeout

csadmind サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。 

デフォルトは 120 秒 (2 分) です。 

service.admin.resourcetimeout

csadmind サービスがリソースカレンダの HTTP セッションをタイムアウトにするまでの秒数を指定します。 

デフォルトは 900 秒 (15 分) です。 

service.admin.sessiontimeout

csadmind サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。 

デフォルトは 1800 秒 (30 分) です。 

エンドユーザーの HTTP タイムアウト値

次の表は、エンドユーザーに適用される、ics.conf ファイル内の Calendar Server HTTP タイムアウトパラメータを示しています。

表 21–5 ics.conf に設定され、エンドユーザーに適用される HTTP タイムアウト値 (cshttpd サービス)

パラメータ 

説明 

service.http.idletimeout 

cshttpd サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。

デフォルトは "120" 秒 (2 分) です。

service.http.resourcetimeout 

cshttpd サービスがリソースカレンダの HTTP セッションをタイムアウトにするまでの秒数を指定します。

デフォルトは "900" 秒 (15 分) です。

service.http.sessiontimeout 

cshttpd サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。

デフォルトは "1800" 秒 (30 分) です。

GSE キューのタイムアウト値

ics.conf ファイルの次のパラメータは、要求されたジョブを Calendar Server が GSE (グループスケジューリングエンジン) キューで走査するまでの時間を秒単位で指定します。

gse.belowthresholdtimeout="3"

キューに含まれるジョブが許容最大しきい値より多い場合、最後のスレッドが常にキューをもう一度走査します。このため、この設定はジョブの数が最大しきい値より少ない場合にだけ適用されます。

デフォルトは "3" です。この値を大きくすると、サーバーがキューを走査する回数が減り、全体的なパフォーマンスを向上できます。ただし、予定のボリュームが増大したためにキューが大きくなりすぎた場合、キューの処理速度を上げるための時間が短くなる可能性があります。これによって全体のパフォーマンスは低下しますが、予定はすぐに更新されます。