IBM Support

Sametime 用 Domino LDAP サーバーおよび Community サーバーの設定に関する考慮点について

Question/Answer


Question

Sametime と Domino LDAP を構成する際の注意点はありますか。

Answer

IBM Sametime と Notes/iNotes を組み合わせて使用した場合、メール等のビューやフォーム上に表示されるユーザー名に対して在席表示がされます。そのため短時間に多数の処理が Community サーバーに (iNotes の場合には Sametime Proxy サーバー経由で) 発生し、LDAPサーバーに対しても大量の名前解決要求が発生します。それらに加えて認証処理の際に発生する名前解決要求も発生します。これらの処理がスムーズに完了しない場合には、クライアントでの操作に対する反応が遅い、あるいはログインができない問題等につながる恐れがあります。

この記事では、IBM Sametime Community サーバーと LDAPサーバーの間での高いスループットと高速な応答性能を実現するための設定について記しています。この記事は IBM Sametime の LDAPディレクトリーとして Domino サーバーを使用することを前提としていますが、他の LDAP ディレクトリーでも適用できる内容があります。

おことわり: パフォーマンスおよびチューニングに関するご質問は弊社サポート部門では受け付けておりません。お客様環境で収集したデータを解析した上でお客様の環境に最適な値をご提案することも弊社サポート部門では実施しておりません。本記事は情報提供を目的に執筆されていますので予めご了承ください。

もくじ

  • 全体像の把握
  • 基本的な考え方と取り組み方
  • LDAPサーバー側の設計と設定
  • Community サーバー側の設定
  • Proxy サーバー側の設定
  • IBM Notes クライアントの設定
  • シングル・サインオン (SSO) の考慮
  • パフォーマンスの確認方法


 
全体像の把握

Community サーバーには LDAP サーバーにアクセスする複数のコンポーネントが存在しますが、最も多くを占めるのが STResolve (名前解決) です。ユーザー検索、在席確認やユーザー認証など名前がかかわる場合にはユーザーを一意に特定するために必ず名前解決が行われます。

ユーザーがメール・ビューを開くと 1 画面あたり 20 - 40 通程度が表示され、それらの送信元の在席確認処理がCommunity サーバー (iNotes の場合は Sametime Proxy サーバー経由) に対して行われ、Community サーバーからは LDAP サーバーに対してユーザーの名前解決要求が送信されます。始業時間帯においては多くのユーザーが短時間にメールを開くことから、LDAP サーバーには大きなスループット性能が求められます。例えば 1000ユーザーの場合、概算で 30通 x 1000人 = 3万程度の LDAP 要求が始業時の短時間に発生します。この数値は iNotes の場合であり、Notes の場合は、内部のキャッシュの仕組みにより、数分の1程度に減少します。

大量の要求を処理するため、Community サーバーから LDAP サーバーへの接続は任意の数を設定できます(下図参照)。各接続にそれぞれ内部キューが設けられ、要求を効率よくLDAP サーバーに送出できるようになっています。Domino LDAPは非同期処理が可能であるため、キュー内の要求は前に送信した要求の応答を待たずして複数の要求を LDAP サーバーに送出できます。LDAP サーバーには複数のワーカー・スレッドが存在し、受信した要求を同時並行で処理します。検索は Domino のビュー検索や全文検索機能等を用いて行われます。

このように Community サーバーは複数の要求を送出でき、Domino LDAP サーバー同時並列処理が可能ですが、LDAP サーバーからの応答を受けた Community サーバーは、その仕組み上、応答受信後の処理が要求送信時の順による(Community サーバーから見て) FOFI (ファースト・アウト、ファースト・イン」の動作であることに注意してください。例えばあるひとつの要求が 5 秒を要したとします。この場合、STResolve はたとえ後続の要求の応答を既に LDAP サーバーから受信済みであっても、送出順に応答が到着するのを待ち、順に Sametime Community サーバーのコアへ処理結果を引き渡します。

Domino LDAP サーバーは STResolve からの要求に対して、CN= が含まれる場合には最初に Base DN検索を行い、ヒットしない場合は次に Subtree 検索を行います。CN= を含まない場合は Subtree 検索から開始します。ただし、インターネット・メール・アドレスの場合は mail スキーマについてのみ Subtree 検索を行います。これらはデフォルトの設定の場合であり、設定により異なる場合があります。

以上の構造を理解した上で、LDAP サーバーの最小応答速度と最大スループット(Community サーバーと LDAP サーバー間)を実現するよう調整する必要があります。


本図は概略説明用であり、実際の構造を正確に表しているものではありません。


基本的な考え方と取り組み方
各種設定が最適でない場合であっても1000ユーザー程度の環境では問題となることは殆どありません。しかしユーザー数の増加に応じて徐々に問題が顕在化する確率が高まってきます。LDAP サーバーへの負荷量と LDAP サーバーの処理能力のシミュレーションは設計段階である程度は可能です。しかし事前のテストではすべてを予測して確認することが難しく、経験上問題事象がサービスイン後に発覚します。そのため、本記事に掲載されている内容をサーバー構築時に行うことはもちろんですが、全面的なサービスインから1、2ヶ月程度は調整期間と考えることを推奨します。

本記事には過去の経験から予測できるすべての対策が記されていますが、調整が必要なものもあります。最大ユーザーに達した後、しばらく運用を続け、ユーザーからの問題報告 (ログインできない、ユーザー検索が遅いなど) がないこと、ログに異常値が記録されないことを確認して Community サーバー - LDAP サーバー間の調整を終了とします。ユーザーからの問題申告の有無に関わらずログを収集して問題の発生、あるいはその兆候がないかを確認する取り組みを、たとえ短期間であっても推奨します。
 

LDAPサーバー側の設計と設定

1. タイムアウト時間、検索結果の最大数、ワイルドカード検索の最小文字数の設定
 
タイムアウト時間は設定可能最小値である 1 秒が理想的です。短くする理由は、全体像で説明した通りひとつでも応答遅れが発生すると後続の応答済みの要求が滞留することになり、スループット性能が低下するからです。また、検索に時間がかかる場合はヒットしない場合が殆どであるためです。

  •  

1秒に設定して、後述するパフォーマンス確認方法でタイムアウトが発生していないかを確認し必要に応じて適切な値にします。一般的には長くても 2秒か 3秒程度で充分です。時間がかかってヒットする、あるいはタイムアウトする場合には何らかの問題が存在していることを示しています。タイムアウトしているLDAP 要求を調べて対策を行います。

Sametime Proxy サーバーでは 10 秒のログイン・タイムアウト時間が設定されています。何らかの理由で処理に時間が要する LDAP 要求が発生すると、後続の認証用要求は Proxy サーバーのタイムアウトに間に合わなくなる場合があります。

検索結果の最大数は、システムの負荷の観点からは少ない方が望ましいです。ユーザー数や同姓/同名の人数にもよりますが、50から100程度が一般的です。ユーザーが目で見ながら探し出すうえで現実的な数字であるからです。

ワイルドカード検索の最小文字数は、システムの負荷の観点からは大きい方が望ましいですが、短い姓名のユーザーを探す場合も考慮し、一般的には 3 あるいは 2 設定されます。LDAPのパフォーマンスを見ながら調整します。デフォルトでは無制限 (0) です。必ず変更してください。

これらの設定は Domino 設定文書の LDAP タブ内で行えます。以下の Knowledge Center 記事を参照して設定してください。

IBM Knowledge Center - 検索処理をカスタマイズして LDAP サービスのパフォーマンスを改善する
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_customizingsearchprocessingtoimproveldapserviceper_c.html
IBM Knowledge Center - LDAP サービスで返すことのできる参照先の数を設定する
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_configuringthenumberofreferralstheldapservicecan_c.html

2. LDAP サーバーの一次ディレクトリー (names.nsf) への参照を抑止する
LDAPサーバーではディレクトリー・アシスタントを使用して、names.nsf 以外のデータベースをLDAPのリポジトリー (2次ディレクトリー) として使用する場合があります。適切な設定をしていない場合、参照する必要のない names.nsf も参照する動作となりパフォーマンスが低下します。以下の記事を参照して設定してください。

names.nsf が殆ど空の状態であっても names.nsf の検索に若干の時間を消費します。names.nsf の検索所要時間が仮に 1ms でも始業時の短時間に数千、数万の LDAP 要求が発生することを考慮すると不要な処理は回避すべきです。なお、2次ディレクトリーのデータベースはパフォーマンスの観点から必ずローカルに配置してください。

IBM Knowledge Center - ディレクトリアシスタントを使用して、LDAP サービスで 1 次 Domino ディレクトリを検索できないようにする
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_usingdirectoryassistancetopreventtheldapservicefr_t.html

LDAP タスク起動直後のタイミングで以下の内容が console.log に記録されていることを確認します (names_japan.nsf は2次ディレクトリー名)。names.nsf がないことに注意してください。names.nsf の同様な行が出現する場合は設定を確認します。

01/01/2018 10:00:00 AM LDAP Server: Starting...
01/01/2018 10:00:00 AM LDAP Server: Serving directory names_japan.nsf in the jp.ibm.com Internet domain
01/01/2018 10:00:00 AM LDAP Schema: Started loading...

また、設定不良の場合には以下のような出力になります。

01/01/2018 10:00:00 AM Directory Assistance database has one or more invalid replicas for domain Fake1.
01/01/2018 10:00:00 AM Directory Assistance database has one or more invalid replicas for domain Fake1 (Notes).

Domino コンソールで show xdir を実行すると以下のように表示されます。LDAPで有効ものが 2 次ディレクトリーだけになっていることを確認できます。



3. ディレクトリー・キャッシュ設定
Domino ディレクトリーと LDAP ディレクトリーの2種類のキャッシュ設定について、notes.ini に以下の設定を行います。この設定は 256MB で、大規模環境でもカバーできる設定です。

LDAP_QRCACHE_SIZE=268435456
NLCACHE_SIZE=268435456

NLCACHE SIZE の実際の使用量は統計情報 (Domino コンソールで show stat を実行) で確認できます。

Database.NAMELookupCacheCacheSize: 101696 (実際の使用量)
Database.NAMELookupCacheMaxSize: 268435456 (設定値)

IBM Name Lookup Cache (NLCache_Size) のデフォルト値について
http://www-01.ibm.com/support/docview.wss?uid=swg21462953

IBM Considerations for Directory Assistance performance optimization. (英語)
http://www-01.ibm.com/support/docview.wss?uid=swg21242384


4. LDAPのワーカースレッド数
notes.ini に以下の設定を行い、スレッド数を増加させます。80から120程度が一般的です。

LDAPMaxWorkerThreads=80

この値は上限値であり、負荷に応じて自動的に設定されます。スレッド数が増えても処理性能はリニアに増加しないためです。実際値は Domino 統計情報で確認できます。statrep.nsf で確認するか、(Domino コンソールで show stat を実行すると以下のような値を確認できます。

LDAP.Sessions.Threads.Peak: 11

Community サーバーからのLDAPサーバーへのセッション数およびLDAP 要求のキュー数の設定(共に後述)を増加させることで、LDAP サーバーに同時に流れ込む要求数が増加して、それに伴って LDAP サーバーのワーカースレッド消費が増大します。スレッドが増加するとCPU負荷が増加します。これら3つの設定値およびCPUの負荷を見ながら最大スループットとなるように調整します。


IBM Sametime wiki : Sametime Standard best practices : Migrating a Community Server from a Domino Directory to Domino LDAP (英語)
https://www-10.lotus.com/ldd/stwiki.nsf/dx/Community_Server_migration_from_native_Domino_to_Domino_LDAP

5. 別名の逆参照 (被参照) 設定
デフォルトでは無効です。特段の理由がない場合を除き、無効のままにします。パフォーマンスに大きな影響を与える設定です。

IBM Knowledge Center - 検索要求で別名の逆参照を設定する
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_configuringaliasdereferencingforsearchrequests_t.html

6. 全文検索設定
サーバー設定文書の設定で全文検索設定を有効にします。Domino LDAP ではビュー検索を利用して高速処理を実現していますが、一部全文検索が必要になる場合があります。

全文索引が作成されていない場合は検索の都度索引を作成して検索を実行し、索引を破棄します。そのためCPU利用率が非常に高まります。

IBM Knowledge Center - LDAP サービスの対象ディレクトリに全文索引を作成する
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_fulltextindexingdirectoriesservedbytheldapservice_t.html

7. ユーザー・リポジトリーおよびディレクトリー・アシスタンス・データベース形式の最新化
IBM Domino 9 でのデータベースのデフォルト形式 (ODSバージョン) は 43 (R6) です。最新のバージョン 51 または 52 にすることでスループットが向上します。対象データベースはDA.nsf (ディレクトリー・アシスタント)、names.nsf および DA.nsf によりカスケードされたディレクトリー・リポジトリー用 DB です。

IBM Knowledge Center - Compact を実行してメールファイルの ODS バージョンを更新する
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_runningcompacttoupdatetheodsversionofamailfile_t.html

IBM Notes and Domino wiki : Notes.inis C - D : CREATE_R9_DATABASES (enables ODS 52) (英語)
https://www-10.lotus.com/ldd/dominowiki.nsf/dx/CREATE_R9_DATABASES

8. データ・リポジトリーは原則一つを推奨
ディレクトリー・アシスタンス機能を使用して、複数のデータベースを LDAP 用リポジトリーとして使用できますが、パフォーマンスの観点からは単一が望ましいです。カスケードするデータベースは 2 ないしは 3 程度に留め、それ以上になる場合はディレクトリー・カタログ機能などを使用して、ひとつにまとめることを推奨します。

LDAP サーバーにおける処理性能は CPU サイクルに依存します。ディレクトリー・データの殆どがキャッシュに格納されるためストレージI/Oの性能は殆ど影響しません。ディレクトリー・アシスタンスを使って複数のデータベースを使用すると、繰り返し同じ検索がデータベース毎に実行され、CPU サイクルが消費されます。データベースが多くなればなるほど応答性能は劣化することになります。

Community サーバーの STResolve の処理は First-Out, First-In (送り出した順番で受信する) 仕組みになっています。後から送出した要求が短時間で処理が完了しても、それより前の処理が完了した後に、STResolve は送り出した順に応答を受信します。喩えると、「追い越し禁止の 1 車線道路」が接続数分 (ST_DB_LDAP_CONNECTIONS_NUMBERの値: Community サーバーから LDAPサーバーへのセッション数) だけ複数存在しているといえます。複数データベースを検索することにより、時間を要する検索が発生する確率が高まります。発生すれば後続の要求は待たされるため渋滞が発生しスループット性能が低下します。

9. ヒット率を高くする
LDAP サーバーの弱点はヒットしない場合のペナルティーが大きいことです。LDAP のデータは殆どがキャッシュに格納されるため、該当ユーザーが存在する場合は瞬時に応答できます。しかし、ヒットしない場合には複雑な処理でヒットする可能性があるエントリーがディレクトリー内に存在しないかを探索するため時間を要します。退職によりディレクトリーでヒットしないことは不可避ですが、以下のことを考慮してください。

検索に特に時間を要するケースは、名がなく姓のみの場合です。例えば CN=Admin/O=IBM です。ディレクトリーに Administrator や System Admin など複数の候補が存在している場合には部分一致するため、LDAP サーバーはディレクトリー全体から部分一致の候補をすべて検索の上で完全一致の照合を行う処理を行います。さらに、姓名双方が存在し間にスペースがある場合と比べて照合に時間がかかります。

典型的な例としては、メール配信不能時に Domino のルーターが送信する CN=メールルーター/O=IBM です。加えておくとパフォーマンスの向上に寄与します。また、CN=G000110/O=IBM のようなグループ名も該当します。

過度の注意は不要ですが、LDAPの処理に長い時間がかかっている場合にはこの点を確認してください。


10. リポジトリー・データベースの日中における更新を避ける
リポジトリーDBに何らかの更新が発生するとビューの更新および全文索引の更新が発生し、大きな負荷が発生します。その間は検索が滞ります。LDAPで使用するビューはサーバー文書なども含まれているため、ユーザーやグループ文書以外の更新も影響を与えます。そのため、日中におけるリポジトリーDBの更新は行わないように、複製設定を適切に設定します。更新は夜間にまとめて短時間に行うようにします。

止むを得ず日中に更新をする場合には、以下の設定を notes.ini に加えます。Updaters は Update タスクの同時実行数です。CPU数より少ない数を設定します。UPDATE_FULLTEXT_THREAD は全文索引処理を Update タスクとは別に (同時に) 行う設定です。

Updaters=2
UPDATE_FULLTEXT_THREAD=1

11. アンチ・ウィルスの設定
Domino プログラムと Data フォルダーについては、アンチ・ウィルス・ソフトウェアの対象から除外することを検討してください。

12. グループ・キャッシュの更新間隔
Sametime Community サーバーでは LDAP サーバーのグループ情報を展開してキャッシュとして取り込んでいます。デフォルトでは 60 分間隔で更新されます。グループが多い場合やユーザーが多い場合で、特段の理由がない場合にはこれを長くします。最大設定値である 1440 分を推奨します。前述の通り、日中における LDAP ディレクトリーの更新は推奨しませんので、それに従った場合 60 分間隔の更新は無意味になります。

以下の Knowledge Center を参照して「Sametime コミュニティディレクトリに追加された新規名を確認する頻度」を変更してください。「追加された新規名を確認する」と記載されていますが、実際の動作としてはキャッシュ内容とLDAPを全て突き合わせる作業が発生し、LDAP サーバーおよび Community サーバー共に負荷がかかります。

更新間隔の起点は前回の終了時点であるため、24時間間隔に設定した場合には更新の実行開始時刻がずれてきます。日中の実行を避けて深夜に実行する必要がある場合には Community サーバーを再起動することを検討してください。Community サーバーが再起動した直後にグループのキャッシュ取り込みが発生します。

IBM Knowledge Center - 一般コミュニティサービスの管理
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/admin/admin_st_mng_gen_comm.html



Community サーバー側の設定

1. LDAPサーバーへのセッション数
同時並行で効率良く処理を行うために、Community サーバーから LDAPサーバーへの接続セッション数をデフォルトの 1 から、LDAP サーバー 1 台あたり 4 に増加させます (LDAP サーバーが 2 台の場合は 8  程度)。8 や 12 など大きな設定も可能ですが、必ずしも大きい数ほど性能が向上するとは限りません。LDAP サーバーの数 x 4 から始めて、パフォーマンスを見ながら調整します。sametime.ini への設定例を示します。

[Directory]
ST_DB_LDAP_CONNECTIONS_NUMBER=8

Community サーバー側では名前解決のための STResolve や認証処理のための STUsers など複数のプログラムが動作し、それぞれから LDAPサーバーへのセッションが存在します。その結果、設定値の 3 ないしは 4 倍程度のセッションが発生します。実際に LDAP サーバーで発生しているセッション数は、LDAP サーバーの統計値 (Domino コンソールで show stat を実行) で最大値と現在の値を確認できます。

LDAP.Sessions.Inbound.Active: 41
LDAP.Sessions.Inbound.Peak: 45


IBM Knowledge Center - Sametime LDAP での複数の接続のチューニング
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/tune/tun_chat_mult_connect.html

2. ホワイトリストの設定
Notes/iNotesのメールビューに表示される社外からのインターネット・メールも、仕組み上 Sametime の在席表示の対象となり、Community サーバー経由で LDAPサーバーへ要求が発生します。これらの要求は社内 LDAP ではヒットしない無駄な検索となるので、Community サーバーのホワイトリスト機能を使い抑止します。ホワイトリストに自社のメール・ドメインをホワイトリストに設定します。実際のデータによると、全 LDAP 要求の概ね 10-20% 程度を削減できます。

ホワイトリストはインターネット・ドメイン単位で設定します。メールの送信元がインターネット・メール・アドレスである場合にのみ適用されます。送信元のアドレスが Notes ID の場合には適用されません。

m@ibm.com や taro@ibm.com のようにユーザー名部分が短い場合には、マッチするケースが多く、検索に時間を要すためスループットの低下を招きます。また、前日から始業時までに配信されたニュースなどの外部インターネットメールが始業時のメール画面に表示されるため、ホワイトリストの設定は LDAP サーバーの負荷が高くなる始業時に特に効果を発揮します。ホワイトリストは必ず設定するようにしてください。sametime.ini の設定例を示します。

[Config]
ST_RESOLVE_WHITELIST=*.jp.ibm.com,*.us.ibm.com,*.cn.ibm.com

実際に抑止された数は、後述の「パフォーマンスの確認方法」内に記載の統計情報で確認できます。
設定が正しく動作しているかは、後述の「4. Community サーバーでのミクロな確認方法」のデバッグで確認できます。Community サーバー起動時に以下のような内容が STResolve のデバッグ・ログに出力されます。

180101_100000.000,INF,LDAP Res,Finished initialization of resolve library
180101_100000.000,INF,Resolve ,StResolveBB::initialize: white list [*.jp.ibm.com,*.us.ibm.com,*.cn.ibm.com]
180101_100000.000,INF,Resolve ,StResolveBB::initialize: black list []
180101_100000.000,INF,Resolve ,StResolveBB::initialize: initializiation of resolve module completed successfully


IBM Knowledge Center - ユーザーとグループのディレクトリルックアップからの特定のドメインの除外
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/config/config_chat_ldap_whitelist.html

3. LDAP への再接続間隔設定
パフォーマンスの観点から、LDAP のセッションはなるべく維持し、再接続を少なくすることが重要です。一方で、複数の LDAP サーバーを使用している場合には負荷分散の観点から、ある程度の頻度での再接続を行い複数あるLDAPサーバーへの接続が偏らないようにすることも必要です。デフォルトはで無効化されているため偏りが発生する場合があります。一般的には 60 (分) などを sametime.ini に設定します。

[Directory]
ST_DB_LDAP_RESPRAY_INTERVAL=60

IBM Knowledge Center - Sametime LDAP 再接続間隔設定のチューニング
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/tune/tun_chat_ldap_respray.html

4. LDAP 要求のキュー数の設定
この設定は Community サーバーから LDAP サーバーへ送信される要求数を調整する、いわばスロットル調整弁、あるいはリミッターにあたります。

始業時などでは Community サーバーからは短時間に大量の LDAP サーバーへの要求が発生します。また、全社員に日中の時間帯にメールを一斉送信すれば、メールのビューに一斉に表示され、ほぼ同時に送信者の在席確認の要求が Community サーバーに送信され、10秒足らずの間に数千、数万の LDAP サーバーへの要求が発生することがあります。

Domino LDAP サーバーは複数のワーカースレッドを使用して多数の要求を並列に処理できます。効率よく次々と処理に要求をスレッドに投入できるように LDAP サーバーには要求プールがあります。しかし過度の要求がプールに滞留すると、LDAP サーバーが過負荷となりスループットが低下する恐れがあります。大量の要求を時間軸で平準化することを意図した、全体最適化のための仕組みがこれにあたります。

Community サーバーは LDAP サーバーに送信した要求の仕掛かり値 (送信数-受信数) を常に把握し、仕掛かり数が ST_DB_LDAP_PENDING_MAX に達すると送信を止め、ST_DB_LDAP_PENDING_LOW まで減ると送信を再開します。この動作は Community サーバーから LDAP サーバーへの接続ごとに独立して適用されます。Community サーバーは各接続に均等に要求を流し込みますが、MAX に達した接続には流し込みを止めます。

通常時は MAX まで達しないように、この文書に記載された各種設定を行うことが重要です。スムーズに流れていれば MAX に達することは殆どありません。MAXまで達する場合には頻繁に停止と送信再開を繰り返すため効率が低下します。要求が充分に LDAP サーバーに届けられていない、あるいは LDAP サーバーが処理仕切れない状況にあると考えられます。MAX まで達したことを確認する方法は後述しますが、不具合(の可能性)を示すサインとなりますので注意が必要です。

原則としてデフォルトの設定を利用し、実際の動作を見ながら調整します。sametime.ini に以下のように設定されています。

[Directory]
ST_DB_LDAP_PENDING_LOW=100
ST_DB_LDAP_PENDING_MAX=120

数千人以上の環境では MAX の値を 160、200 などの値にすることも検討してください。要求量が多い環境では始業時などに 時折 MAX に到達してしまう場合があります。MAX と LOW の差をやや大きく取ることで送信停止・再開の頻度を下げ、効率を高められます。ただし、連続的に停止・再開を繰り返している状況がある場合には、他の設定変更の必要があります。

IBM Knowledge Center - Sametime LDAP 内部キューを管理する
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/tune/tun_chat_ldap_queue.html

5. Domino LDAP に対応したオブジェクト名の使用
LDAP の標準オブジェクト名である inetOrgPerson、groupofNames については dominoPerson、dominoGroup を使用します。こうすることで、それぞれ Domino ディレクトリーのユーザー文書とグループ文書に明示的にマッピングされるためです。

IBM Knowledge Center - Domino LDAP スキーマ
https://www.ibm.com/support/knowledgecenter/ja/SSKTMJ_9.0.1/admin/conf_thedominoldapschema_c.html

6. LDAP フィルター式の再検討と最適化
インストールの段階で、mail、cn、uid 等がLDAPの各種クエリーの検索対象スキーマとして設定されています。特にLDAPへの要求を多く出すCommunity サーバーについては、必要に応じてこれらを追加、削除することを検討してください。これらは Sametime System Console (SSC) の LDAP 設定を通じて変更可能です。Community サーバーの stconfig.nsf の LDAPServer カテゴリー内の文書でも変更可能性ですが、SSC の LDAP 設定を変更すると上書きされる場合があります。正式には SSC で設定変更することを推奨します。

現在の設定を確認する目的で stconfig.nsf の LDAPServer カテゴリー内の文書を参照します (SSC の設定画面では項目の設定はできますがフィルター式は表示されません)。
 

  • Search filter for resolving person names は、名前検索を手動で行う場合や Notes のビューやフォームでの在席表示を行う際に使われます。
  • Search filter to use when resolving a user name to a distinguished name は厳密にユーザーを特定する際に使われます。一意になるものが設定されます。


シンプルな例を示します。1行目では Notes のビューやフォームで在席確認が動作するために必須な cn (前方一致) と mail (完全一致)、それに加えて姓 (前方一致) での手動検索ができるようになっています。uid は ユーザー文書の短縮名にあたりますが必須ではないと判断された例です。検索利便性を高めるために givenname などを指定することもできますが、項目を増やすと効率性は低下します。ユーザー文書のフルネーム・フィールド (cn に相当) に必要な名前をすべて入れておくことで (但し、一意であること)、検索のフィルター式をシンプルにできます。
2 行目では mail (インターネット・メール・アドレス) と cn (ユーザー文書のフルネーム) のいずれかが完全一致で検索にヒットするように構成されています。
 

  • Search filter for resolving person names: (&(objectclass=dominoPerson)(|(mail=%s)(cn=%s*)(sn=%s*)))
  • Search filter to use when resolving a user name to a distinguished name: (&(objectclass=dominoPerson)(|(mail=%s)(cn=%s)))


mail、cn、uid など一般的スキーマでのクエリーはビュー検索で実行されますが、そうでないものの場合は全文検索で実行される場合があります。全文検索はビュー検索と比較すると低速であるため、場合によっては大幅なスループット低下を招きます。このことは、*%s* のような部分一致のフィルター式でも同様です。ビュー検索を使って高速に処理するためには、前方一致、あるいは完全一致で検索するようにフィルターを構成します。

Sametime 利用者を制限するために、あるいは検索にヒットするユーザーを制限するために、名前検索では使われないスキーマ (フィールド) をフィルター式に組み込むケースがありますが、LDAP サーバー側での検索処理にビュー検索が使えないため、全文検索が使用され時間を要します。小規模では有効な方法ですが、大規模になると LDAP サーバーの応答性能が低下してスループットに影響を及ぼすことになります。

7. 逆参照 (被参照) 検索の明示的無効化
Community サーバーはデフォルトで逆参照を有効化して LDAP サーバーに要求を送信します。LDAP サーバー側で逆参照は無効化されているため実際に逆参照が実行されることはありませんが、無駄な処理が発生し、トレースログへの記録処理が発生します。以下の設定を sametime.ini に入れることで逆参照要求を抑止できます。

[Directory]
ST_DB_LDAP_DEREF=0

8. ダミー・クエリーの設定 (設定変更は原則不要、参考記載)
Community サーバーは 1 分間隔(デフォルト)でダミー・クエリーを LDAP サーバーへ送出する機能を有しています。この目的は、LDAP サーバーや負荷分散装置が一定期間トラフィックがない接続を切断しないようにするためです。LDAP サーバーへの再接続は負荷増加と時間損失を招くため、それらを回避する目的でこのダミー・クエリーは存在しています。

Community サーバーから LDAP サーバーへの要求が発生している場合は 1 分間隔でダミー・クエリーが送出されることはありません。要求が存在しない状態が発生すると 1 分間隔でダミー・クエリーが送出されます。クエリーの内容は軽いことから LDAP サーバーへの負荷は限定的です。そのため、この設定を変更する必要はありません。

間隔をあまり広げ過ぎた場合や、停止させた場合 (値を 0 にする) には LDAP サーバーと Community サーバー間の接続障害が発生する場合があります。変更する場合には注意が必要です。Domino LDAP サーバー使用時に 30 での正常動作、60 でのログイン障害発生の報告があります。

[Directory]
ST_DB_LDAP_KEEPALIVE_INTERVAL=1

IBM Knowledge Center - Sametime LDAP 接続確認の間隔の設定のチューニング
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/tune/tun_chat_ldap_keep_alive.html

9. 公開グループ内のユーザー数制限
ユーザーが連絡先リストに公開グループを追加するとグループ内のメンバーが展開されて表示できます。一度に大きな負荷が発生することから sametime.ini に以下の設定を行い、最大数を 1から1000 の範囲で制限します。0 にすると無制限になるため 0 は使わないでください。

[Directory]
ST_GROUPS_MAX_MEMBERS=30

IBM Knowledge Center - 連絡先リストのサイズを制御するための詳細設定
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.0/admin/tune/tun_chat_contact_list_size.html


Proxy サーバー側の設定
以下の Knowledge Center を参照して設定してください。

IBM Knowledge Center - LDAP パフォーマンスの調整
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/tune/tun_ldap_performance.html

利用ユーザーが数千を越える構成の場合にはキャッシュ設定 (サイズとタイムアウトの増加) を行ってください。検索結果キャッシュ数はユーザー数程度。属性キャッシュ数はユーザー数の2-4倍程度にします。タイムアウトは 86400 にすると 24時間有効になります (下記の Knowledge Center の項目 10 と 11)。

IBM Knowledge Center - 統合リポジトリー構成における LDAP リポジトリーのパフォーマンスの向上
https://www.ibm.com/support/knowledgecenter/ja/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/twim_performance.html

および、そのサブ・トピック: IBM Knowledge Center - Lightweight Directory Access Protocol のパフォーマンス設定
https://www.ibm.com/support/knowledgecenter/ja/SSAW57_8.5.5/com.ibm.websphere.nd.doc/ae/uwim_ldapperfsettings.html



IBM Notes クライアントの設定

Notes クライアント (Standard版) の設定画面内の「Sametime」-「サーバーコミュニティー」- <エントリー> - 「オプション」タブ - 「在席状況の参照に、階層付きの名前を使用する」にチェックをいれます。これによりビューやフォームの在席確認時、ユーザー名を CN=Taro Yamada/OU=Japan/O=IBM のように DN 名で Community サーバーに送信するようになります。チェックがない場合には Taro Yamada/Japan/IBM を送信します。CN=...の場合は高速な Based DN 検索が使用されるのに対して CN=ではない場合には Subtree 検索が実施され、処理に時間を要します。

Notes クライアントに組み込みの Sametime を使用する場合はこの設定を推奨します。iNotes の場合にはすべて CN= が付いた形が用いられますので考慮は不要です。
 
plugin_customization.ini や managed-settings.xml 等で設定を配布する場合には、コミュニティー設定の useCanonicalNamesOverride を使います。例を以下に示します。

com.ibm.collaboration.realtime.community/host=sametime.ibm.com (接続先サーバーの設定)
....各種設定値....
com.ibm.collaboration.realtime.community/useCanonicalNamesOverride=1


Notes クライアントの設定画面は以下のようにチェックが入った状態でグレーアウトされ、LDAP 検索に最適な設定が固定されます。



IBM Knowledge Center - Sametime 組み込み型クライアントでの受信ボックスの在席確認の有効化
https://www.ibm.com/support/knowledgecenter/ja/SSKTXQ_9.0.1/admin/config/config_client_inbox_aware_embed_client.html


シングル・サインオン (SSO) の考慮

SSO のトークンには有効期間が設定されています。業務時間を考えると600分から720分程度に設定される場合が殆どです。30分程度の短時間にすると使い勝手に影響を与え、再認証 (トークンの検証) のために LDAP サーバーへのアクセスが頻繁に発生します。特段の理由がない限り、長めの時間を設定することを推奨します。

以下の内容は LDAP サーバーとの関連はありませんが参考情報として記します。

 

  • iNotes 内蔵の Sametime を使用する場合、SSO のための LTPA トークンは iNotes メールサーバー側から取得され、Sametime のログインに使用されます。そのため、直接 Sametime Proxy サーバーにログインする場合と比較して LDAP サーバーへの負荷はほぼ同じです。

 

  • Notes クライアントでは上記の考慮は不要です。Notes クライアント内蔵の Smaetime で Domino シングル・サインオンを使う場合にはまず Community サーバーから NRPC (1352ポート) を使って LTPA トークンを取得します。Domino サーバーはユーザーが認証されていることを確認し、ユーザーに LTPA トークンを渡します。この時、LDAP サーバーは使わず1次および2次 Domino ディレクトリーの範囲で検証を行います。したがって LDAP サーバーには負荷は発生しません。なお、Community サーバーにはNRPCでの接続が大量に発生するため Community サーバーの notes.ini に server_session_timeout=1 を設定し、1分間でセッションを切断するようにします。デフォルトではセッションを 4 時間維持するため Community サーバーに大きな負荷がかかりサーバー動作の安定性に影響を与える場合があります (Sametime クライアントの通信は 1533 ポートを使い、NRPC の 1352 ポートは使用しません)。
  •  
  • server_session_timeout=1 を設定しない場合、環境にもよりますが 15000-16000名程度がログインした時点でポート・リソースが枯渇する可能性があります。(将来的なユーザー増加を見込んで)15000名を超える場合は MUX (Sametime Community サーバーの通信部分を担当する機能) を別サーバーに外だしすることを検討してください。server_session_timeout=1 を設定する場合でも20000名を超える場合には同様の検討を推奨します。


パフォーマンスの確認方法

マクロな視点から観測を行い、問題点あるいはその兆候が発見された場合にはミクロな視点で原因の追及に当たります。ユーザーが増えることで問題が顕在化する可能性がありますので、継続的にパフォーマンスを確認し、上記の設定を見直すなどの対策を取ることを推奨します。
 
1. Community サーバーでのマクロな確認方法
Community サーバーの \Domino\Trace フォルダーにある StResolve_YYMMDD_HHMM_nnnn_[3桁連番].csv を表計算プログラムなどで閲覧します。このファイルはデフォルトで1週間に1つ作成され、1分間隔でその1分間の統計情報が1行ずつ記録されます。朝のピーク時間などを更に細かく確認したい場合には、sametime.ini の [Config] セクションに ST_DIAGNOSTICS_INTERVAL=10 (秒) を設定します。

 

 

項目
説明
APP_ReqQueueSize 統計情報を取得した時点で Community サーバー内のキューに保留されている送信待ち要求数。この数値は原則として 0 が望ましい (時折 100程度以下の数値が単発で出る場合は無視可能)。

継続的に 0 以外が出力される場合や、200-300超の数値が出力される場合はスループット能力が充分でない可能性があるppことを示す。

0 以外の数値が継続的に出ることは、どのセッションにおいても LDAP サーバーでの仕掛かり数が相当数あり、送信の一時停止、再開が繰り返され、処理が逼迫していることを示す。
APP_ResolveReqPending 統計取得期間 (デフォルトでは1分間) に発生した要求数から応答数を引いた数。0 が基本 (統計値を取得した瞬間にたまたま 0 以外が出力されることはあり)。

始業時などスループットの極限時に (処理数が多く) 応答速度が低下したことにより、この数値が連続的に出現する場合がある。要求数の1-2%程度ならば無視できますが、それ以上の数値が連続的に出現する場合は応答性能が低下していることを示唆している。ユーザーに影響がでるほどの応答時間か否かを確認する。
APP_ResolveAvgTime STResolve の名前解決所要平均時間。LDAP の処理時間でないことに注意。LDAP のタイムアウトが 1 秒でも、スループットが低下するとこの値が 15 秒になることもある。
  • 50 - 100ms 以下がめやす。10ms以下が理想的。
STLDAP_RespAvgTime_SEARCH_[ホスト名] そのホストでの STResolve の名前解決所要平均時間。ただし、下記 _MAX に分類されたもの以外の平均。
  • 50 - 100ms 以下がめやす。10ms以下が理想的。高負荷時間帯においてはこの限りではない。
STLDAP_RespAvgTime_SEARCH_[ホスト名]_MAX 名前解決所要最大時間の平均。平均から大きく乖離したものを自動的に選別し平均したもの。最大値ではないことに注意。
  • この数値が大きく、且つ上記平均値 (STLDAP_RespAvgTime_SEARCH_[ホスト名]) も大きくなる場合は全体に与える影響が大きく、にスループットが低下することが多い。
  • 単発で MAX の値が大きいものが記録されたものの平均値が上がらない場合は、発生数は相対的に少なく全体に影響を与える可能性は低い。
APP_WhiteBlackListRejectNum ホワイトリスト/ブラックリストにより LDAP サーバーへの送信がブロックされた要求数。ホワイトリスト/ブラックリストの効果測定ができる。
APP_ResolveRespZeroMatchNum ヒットしなかった要求数。総要求数の 1 割前後発生することが一般的に観察される (ホワイトリスト設定後)。スループット性能の低下につながるため、あまり多い場合には調査する。
STLDAP_TimedOutLdapResult LDAP サーバーからの応答待ちが長期化しタイムアウトした回数。通常は 0。
STLDAP_TimedOutOnPendingLow 一時、LDAP サーバーへ送出が保留されたものの再開閾値まで仕掛かり数が減少しない状態が長期化しタイムアウトした回数。通常は 0。上とあわせてこの二つのタイムアウトが発生する場合には、他の数値に異常値が記録されます。多少のスループット性能が低下した場合でもこの値は 0 であることが殆どです。0 以外が出現する場合には相当に状態が悪いことを示します。


分析事例: 約 1 万ユーザーの環境における朝のピーク時の例と、昼頃に発生した異常時を示したものです。フレックス制であるため朝のピーク時のログイン時は6000ユーザー前後です。

 

 

  • E 列の応答速度を見ると全体として非常に良好な応答速度であることが分かります。50 から 100ms超前後のものが多く決して最良とは言えませんが相当数の要求を処理していることから、応答速度が増加することはトレードオフとして見るべきです。LDAP サーバーの 9:16の統計情報では LDAP.Average LDAP Search time が 0.003 でした。このことから、LDAP サーバーは充分に高速に処理ができていて、応答平均速度の増加は LDAP サーバーの能力不足が主たる原因ではなく、大量の入出力に起因していると考えられます。
  • B列のキュー送出滞留数は頻繁に出現していますが 0 が挟まることも多く、累積するような状態ではないので無視できる状況です。
  • F列の応答平均最大速度はやや高めであることが問題と言えます。調査、対策が必要ですがユーザー利用では支障が出ていない状況です。


11:51 から状況が急変します。

  • E 列の応答平均速度と F 列の応答平均最大速度が急激に悪化します。それにあわせて、
  • B 列のキュー送出滞留数が増加していきます。
  • C 列の名前解決要求数は異常前と変わらないにもかかわらず、
  • D 列の名前解決応答数は極端な低下を見せます。
  • G 列には滞留キューがタイムアウトしたことが記されています。

調査の結果、CN=Admin/O=IBM のような姓のみのユーザー名で、LDAP サーバー上に存在しない Notes ID を使い 1000 名程度にニュースをメールで配信したことが原因だと判明しました。Admin から始まる LDAP エントリーは多数あること、そしてこのユーザーが LDAP サーバーに存在しなかったことから検索に3秒程度を要していました。3秒を要する要求が限られた数のセッション内に多数入ったため、その他の要求がキューから溢れてしまう状況となりました。

11:57 になると D 列の名前解決応答数が C 列の名前解決要求数を上回るようになります。CN=Admin/O=IBM の名前解決処理がすべて終了して滞留していた要求を処理していることが分かります。それでも滞留数が膨大であるため正常化までに3分を要しています。

始業時のピーク時には余裕をもって処理できる環境であっても、ちょっとしたことががきっかけでログイン不能状態や正常な利用が阻害される状況が発生する場合があります。メール画面は殆どのユーザーが開いているため、メールの一斉配信を行うと送信者の ID に対する在席確認が一斉に発生します。このようなユーザーID が LDAP サーバーに登録されていることを確認してください。また、このような問題は常時発生するものではないため、サービス開始後ある程度の期間は様子を見ることを推奨します。



IBM Sametime 9 Community サーバー:ディレクトリー・アプリケーションの診断データの機能強化
http://www-01.ibm.com/support/docview.wss?uid=swg21882656

2. Proxy サーバーでの確認方法
Proxy サーバーには 10秒のログイン・タイムアウト設定が組み込まれています。タイムアウトが発生すると SystemOut.log に以下が記録されます。一度でもこれが発生することがないようにします。一度でも発生する場合は、LDAPの処理で10秒近く、あるいはそれ以上要していたことを示しています。これは常時監視すべき項目の一つです。

CommunityServ W com.ibm.collaboration.realtime.stproxy.services.community.CommunityService doService, SID: 893f3455-4821-46ae-b507-5c90e80929c6 CLFRX0030E: ログインが 10 秒以内に完了しませんでした。 ユーザー CN=Taro Yamada/O=IBM はログアウトされます。

3. LDAPサーバーでのマクロな確認方法
コンソールで sh stat (ldap) を実行すると、その時点での統計情報を入手できます。遡って調査するためには Domino サーバーで統計情報の収集設定を行って下さい。確認すべき項目を以下に説明します。
 

項目
説明
LDAP.Average LDAP Search time: 0.008 検索所用時間。めやすは 0.01 前後/以下です。
LDAP.Total LDAP Timeouts: 54 タイムアウト回数。ゼロが基本です。稀に発生しますが、数が多い場合や継続的に発生する場合には原因を確認し対策を行います。
LDAP.Longest LDAP Search request
LDAP.Longest LDAP Search time
最長時間を要した要求内容。問題解決の手がかりとします。
LDAP.Search.Longest.AverageTime.nn
LDAP.Search.Longest.Count.nn
LDAP.Search.Longest.Entries.nn
LDAP.Search.Longest.Pattern.nn
最も検索に時間を要した検索パターンを示したもので、時間、回数、そのクエリーでのヒット件数、検索パターンが記録されます (nn は01から20)。

時間と回数でおおよその影響を推測できます。回数が多ければ短い時間でも影響は大きくなります。逆に回数は少なくても時間が長いと局所的ですが大きな影響がでます。パターンを確認して対策を検討します。タイムアウトしたものもここに表示されます。
FT.Search.Average.TimeMS = 445
FT.Search.Count = 1
FT.Search.Total.ActualHits = 35
FT.Search.Total.Results = 35
FT.Search.Total.TimeMS = 445
全文検索の回数を確認します。Domino LDAP サーバーでは基本的に全文検索を使用しません。回数に不審点がある場合には原因を調査します。全文検索は検索コストが高いため応答速度が増加しスループット性能が低下します。

 


4. Community サーバーでのミクロな確認方法
Community サーバー側にデバッグ設定を追加することで要求1件毎の詳細データを取得できるようになります。どの要求が処理の遅延を起こしてかなど、ピンポイントでの調査が可能になります。

設定方法
sametime.ini の [Debug] セクションに以下の設定を追加します。デバッグ設定によりサーバーへの負荷は多少高まりますが、概ね10%程度のCPU使用率の増加であり、直ちに機能に影響を及ぼす程ではありません。この設定を有効にするには Community サーバーの再起動が必要です。

問題発生時の調査のため、および潜在的な問題を早期に把握するためにも、ユーザーが増加し安定稼動が確認できるまでの期間は有効にしておくことを強く推奨します。先頭に # を付けることで無効化できます。

[Debug]
VP_LDAP_TRACE=1
VP_REG_TRACE=1
VP_RESOLVE_TRACE=1
VP_RESOLVE_DEBUG=1
ST_DN_UTIL_DEBUG=1
ST_TRACEFILE_SIZE=50
ST_TRACEFILE_CNT=20

最後の2行は50MBのファイルを20個作成する設定です。21個目は作らずローテーションで記録されます。
STResolve、STUsers などそれぞれのトレース・ファイル出力に影響します、概ね、3、4倍の空き容量があることを確認してください (ここでは 50MB x 20ファイル x 4 = 4GB)。50 と 20 は適宜調整してください。

調査1 (LDAP処理時間の確認)
Trace フォルダーに stresolve_yymmdd_nnnn_nnnn_nnn.txt ファイルが作成されます。このファイルから "complete duration" を含む行を grep などを使い取り出します。テキスト処理を行って CSV 形式にし、セッションID (connection 値) と セッション内連番 (msgID) でソートすると処理がしやすく便利です。このログには複数のセッション処理が書き込まれているため、「セッション別」->「時間」の順でソートすると状況が見えるようになります。

180110_100000.000,INF,LDAP Res,Search returned, context [-1] connection [00D6D848] msgId [4] complete duration [15] result [0/Success] name [CN=Taro Yamada/OU=Japan/O=IBM] state [1]

complete duration は処理時間を表します。この数値が大きくなるケースには 2 種類があります。ひとつは、極めて長時間の complete duration が存在しているため後続も影響を受けて大きな数値がでるパターン。もうひとつは、相対的に長めの処理時間の要求 (例 100 - 500ms) の処理が連続発生したために徐々に後続に影響が積み上がるパターンです。

処理が長くなる場合の殆どはヒットしないケースです。LDAPサーバーはキャッシュによりヒットする場合には高速に応答できますが、ヒットしない場合は検索文字列を要素にわけて subtree 検索するため時間を要します。退職者などヒットしないことが不可避な場合もありますが、存在するユーザーだが LDAP サーバー上に存在しない場合は追加します。これは業務 ID などでよく見られます。

 

 

 

項目
connection セッションID
msgId セッション内の連番。1から255まで。その後 1から再度開始、あるいはこのIDのセッションは破棄される。
complete duration 処理に要した時間 (ms)
これは、LDAPサーバーでの検索時間ではなく、Community サーバー内においてキューに入ってから応答が返るまでの時間です。処理が遅いものがあると、後続の処理も (LDAP内では高速に処理されたとしても、Community サーバーから見た complete duration の) 時間が長くなる場合があります。
result LDAP としての応答です。
  • 0/Success: 検索成功。ヒットするものがない場合でも「処理が完了した」の意味で Success となるので注意。
  • 32/No such object: Base DN検索で該当するものがなかった。
  • 3/Timelimit exceeded: タイムアウト。
  • 4/Sizelimit exceeded: 指定した件数 (100)などを越えるヒット。
  • 34/Invalid DN syntax: 解釈不可能な検索文字列。
  • 81/Can't contact LDAP server: LDAPサーバーに接続できず。
name 検索文字列
state 状態。result の結果との組み合わせで意味は異なる。


分析事例: Timelimit exceeded が起点となって後続の処理に遅延が発生していることが分かります。この場合の影響は後続の 3 つの要求のみに限定されているため問題とはなりません。影響の度合いが大きい場合には原因となった先頭の処理についてさらに深く調査します。


調査2 (LDAP 要求のキュー数)
Trace フォルダーに stresolve_yymmdd_nnnn_nnnn_nnn.txt ファイルが作成されます。このファイルから "Resuming to send requests to LDAP" を含む行と"Will not request new operations"を含む行を grep などを使い取得します。これが存在しない場合、処理がスムーズに流れていることを示しています。

このようなメッセージが存在する場合は STResolve の処理がスムーズでないことを表しています。原因は様々です。処理が滞る理由を全体にわたって確認してください。LDAP サーバーの CPU 消費、STResolve の所要時間、個別の要求毎に処理時間が長くなっていないかなどです。

このメッセージは Community サーバーから LDAP サーバーへの複数の接続ごとに発生します。まれに単発で発生する場合は、処理に時間を要する要求が突発的に発生しキューの処理が滞った可能性を示唆しています。LDAP サーバーの処理能力が足りない場合、あるいは処理に時間を要する要求が多発する場合には、複数のこのメッセージが同時に発生することが多く見られます。その場合は複数の接続で同時に処理が止まっていることを示しています。

190101_100000.000,FTL,LDAP Res,Warning: 120 operations waiting for response. Will not request new operations until at most 100 are left
190101_100001.000,FTL,LDAP Res,Number of pending operations dropped below 100. Resuming to send requests to LDAP

これが確認できた場合には、


5. LDAPサーバーでのミクロな確認方法
LDAPサーバーでの処理自体に時間を要している場合には、LDAP サーバーのデバッグログを取得して調査します。

設定方法
notes.ini に以下の設定を行い Domino サーバーを再起動します。102400 は 100MBの設定です。LDAPDEBUG= 以外の 2 つは常時設定しておいて差し支えありません。LDAP でのデバッグは CPUに負荷がかかり、出力内容も大量になります。実施時期には考慮を払い、なるべく短時間で終わるようにします。事前に、どの程度負荷が発生するかを確認しておくと良いでしょう。設定したログ容量に達すると記録が停止されます。ローテーション形式で記録はされませんので注意してください。

Debug を停止させるには Domino コンソールから set config LDAPDEBUG=0 を実行します。再起動不要で、1分程度すると停止します。下記最初の2つが設定済みの場合は set config LDAPDEBUG=7 を実行することで、Domino サーバーの再起動なしにデバッグログの取得を開始できます。

Console_Log_Enabled=1
CONSOLE_LOG_MAX_KBYTES=102400
LDAPDEBUG=7

調査方法
デバッグ・トレースに関する情報は非公開ですが、標準的な LDAP の用語で記録されているため、LDAP 検索の形式や渡された条件、所要時間などを確認できます。詳細は省略します。

 

 

Document information

More support for: IBM Sametime

Component: Community Server

Software version: 9.0, 9.0.0.1, 9.0.1, 9.0.1.1

Operating system(s): AIX, Linux, Windows

Software edition: Communicate, Complete, Conference, Limited Use

Reference #: 2012561

Modified date: 14 September 2018