はじめに

この記事では、Domino アプリケーションにおけるパフォーマンスの問題をどのように識別し、解決するのかを引き続き解説します。パート 1 では、問題を識別するための実証済みの方法や、ビューの索引とエージェントを最適化するヒントを取り上げました。パート 2 では、Domino アプリケーションの問題箇所を識別するために役立つ Lotus Notes/Domino 7 の新規ツールを取り上げます。コードのヒントを説明するためにパート 1 で作成したエージェントにこれらのツールを使用することで、パフォーマンスの問題点を明らかにします。

上に戻る

アプリケーション・パフォーマンスのトラブルシューティング: データ収集用の新規ツール

長年、企業におけるエージェントに関する議論を聞いてきましたが、トラブルを抱えたエージェントを把握することは非常に困難だという意見が多いようです。これは、多くのエージェントが同時に実行される HTTP 環境で特に顕著で、どのエージェントが CPU またはメモリを大量に消費しているのかを検出しにくくしています。また、問題のエージェントを特定した場合でも、エージェント・コードで最適化すべき部分を見つけるために、莫大な作業を必要とします。このような問題を解決するため、Lotus Notes/Domino 7 には新しい診断ツールが導入されています。

上に戻る

Domino Domain Monitoring でのアプリケーション調査

Domino Domain Monitoring (DDM) は Lotus Notes/Domino 7 の新機能です。これは、すべてのサーバータスクに追加されるフレームワークで、システム管理者によって指定された簡単な設定に基づき、サーバータスクがさまざまな状態を自己モニタリングすることを可能にします。DDM は Domino 7 サーバーだけをモニターし、自己モニタリング用のコードを持たない以前のリリースの Lotus Domino はモニターしません。この記事では、パフォーマンスの問題に関連するアプリケーション調査について解説します。

アプリケーション調査がカバーするのは、エージェントと Web サービスです。特に、Agent Manager タスクで実行されるスケジュール済みエージェントとイベント駆動のエージェントや、HTTP タスクで実行される Web エージェントと Web サービスを扱います。次のアプリケーション調査を利用できます。

• CPU 使用率でランク付けされたエージェントと Web サービス
• メモリ使用量でランク付けされたエージェントと Web サービス
• 設定よりも長く実行されたエージェントと Web サービス
• スケジュールよりも遅れて開始したエージェント (Agent Manager にのみ適用)
• エージェントと Web サービスのエラー調査
  • エージェントのセキュリティ
  • 全文索引のないデータベースでの全文検索操作
  • エージェントのタイムアウト
  • 設計の更新中にエージェントを無効にした「設計の更新」

この記事では、CPU、メモリ、全文検索に関する調査を取り上げ、それぞれがパフォーマンスの問題のトラブルシューティングにどのように役立つのかを解説します。

数多くのサーバー設定情報を含む Events4.nsf ([Monitoring Configuration] データベース) が強化され、すべての DDM Probe用の設定を保持するいくつかの新しいビューが追加されました。

Lotus Notes/Domino 7 の Events4.nsf に含まれるデフォルトのProbeは、そのまま使用することも、組織のニーズに合わせて変更することもできます。

上に戻る

アプリケーションの CPU使用量調査

CPU Usage Probeについて見ていきましょう。CPU Usage Probeは、各エージェントによって使用された CPU を測定します。測定はエージェント単位で行ないます。エージェントの実行時間の長さにかかわらず、特定のエージェントが開始してから終了するまで CPU を測定します。指定されたプロセス内の多数のアクティブ・スレッドの 1 つでエージェントが実行された場合でも、CPU Usage Probeは 1 つのエージェントだけが使用した CPU を測定します。各エージェントが異なる複数のスレッドで実行される Java エージェントの場合は、そのエージェントに属するすべてのスレッドを測定します。エージェントの測定結果は、そのエージェントに属するすべてのスレッドによって使用された CPU の合計となります。この特殊な測定方法は、DDM 調査を介した測定以外では使用されません。

Application Probesの設定はたいへん簡単です。CPU Usage Probeの設定を図 2 に示します。これ以外のApplication Probesの設定もほとんど同じです。

Probeのタイプ (Application probe/ranked by CPU usage) を選択した後、モニターするサーバーを選択します。次に、Agent Manager で実行されるスケジュール済みエージェントをモニターするか、Web エージェント/Web サービスをモニターするかを選択します。そして、Probeの詳細を選択します。

エージェントによって使用される CPU の量に基づいて生成する警告のレベルを 4 段階 (警告(低)?致命的) まで選択できます。エージェントの実行中に、設定されている量よりも多く CPU をエージェントが使用した場合は、適切な警告レベルのイベントが生成されます。event タスクはイベントを処理し、[Domino Domain Monitoring] データベース (ddm.nsf) に出力を表示します。

この記事で使用したエージェントを実行するときの設定例を図 2 に示します。最小レベル (警告 (低)) を 1 秒に設定すると、ほとんど CPU を使用しないエージェントを含め、例で用いたすべてのエージェントでイベントが発生します。この設定ではあまりにも多くの情報が生成されるので、実際のシステムでは、このように低いしきい値を設定することはありません。

説明のために、私たちはパート 1 の記事で解説した手法を使用して 4 つのエージェントを作成しました。エージェントの名前は、エージェントの実装に使用した手法に対応しています。たとえば、db.Search メソッドを使用するエージェントの名前は、Slow Mail Agents (dbSearch) です。ddm.nsf に表示された出力は次のとおりです。

図からもわかるように、CPU 使用量調査は各方法の相対的な効率を示します。

• Slow Mail Agent (AllDocs) の CPU 使用量は 1034 秒です。
• Slow Mail Agent (dbSearch) の CPU 使用量は 624 秒です。
• Slow Mail Agent (GetMail_ftSearch) の CPU 使用量は 281 秒です。
• Slow Mail Agent (GetMail_ByView) の CPU 使用量は 56 秒です。
• Slow Mail Agent (ByViewEntryCollection) の CPU 使用量は 50 秒です。

アプリケーションメモリ調査

次に、Memory Usage Probeを見ていきます。DDM の目的は、各エージェントのステータスレポートを作成することではなく、問題点を明らかにすることです。Memory Usage 　Probeは、各エージェントによって使用されるメモリの量を測定し、評価します。サーバーのパフォーマンスをあまり低下させずに意味のある情報を提供するために、この調査は、エージェントによって使用される各バイトではなく、バックエンドのメモリプールを測定します。Domino のメモリ管理はたいへん複雑で、組織のニーズに応じてさまざまなメモリプールが使用されています。バックエンドのメモリプールは、Domino オブジェクト (NotesDocument や NotesSession など) にメモリを割り当てるために使用されます。バックエンドのメモリプールは全体のメモリ使用量と強い相関関係を持つので、各エージェントが使用するメモリを 1 バイト単位で測定しなくても、メモリの消費を把握できます。ここでは、バイト単位で測定しないため、詳細な数値はレポートせず、メモリ使用量のランクをレポートします。

高いメモリ使用率で実行されるエージェントは、サーバーの安定性を脅かす可能性があり、十分な注意が必要です。

エージェントによって使用されたメモリはエージェントの終了後に解放されるので、ランキングはエージェントの実行中の最大メモリ使用量に基づいています。CPU 使用量調査と同様に、プロセス内の他の多くのアクティブ・スレッドに交じってエージェントが 1 つまたは複数のスレッドで実行される場合でも、メモリ使用量調査はそのエージェントに属するスレッドだけでメモリを測定します。

エージェントのランキングは、次の 2 つの要因に依存します。1 つは、このエージェントによって使用される、利用可能なバックエンド・メモリのパーセンテージです。もう 1 つは、同じプロセス内で実行されている他のエージェントとの間で、エージェントがメモリを共有する必要があるかどうかです。Web エージェントを HTTP で同時に実行するよう設定したとき、利用可能なメモリプールは、同時に実行されるすべてのエージェントで共有されます。負荷のピーク時にサーバーのパフォーマンスを維持するには、各エージェントをスリム化することが必要です。

一方、メモリプール全体を使用可能な環境で実行されているエージェントは、より多くのリソースを使用できます。このような状況になるのは、HTTP 設定でエージェントを順番に実行するよう設定されている場合、または Agent Manager でエージェントが実行される場合です。Agent Manager では、同時に実行するエージェントは、それぞれ異なるプロセスで実行されます。エージェントを HTTP で実行した場合 (エージェントの同時実行モード) と Agent Manager で実行した場合では、Memory Application Probeで同じエージェントが異なるランクとなります。次の例では、同じエージェントを HTTP と Agent Manager で実行しています。HTTP でのランクは「非常に高い」のに対し、Agent Manager では「高い」になっています。

メモリアプリケーション調査は、エージェント実行時の最大使用メモリを測定します。2 つの Java エージェントの例を使用して、メモリアプリケーション調査が何を示し、コードの最適化にそれをどのように活用するのかを説明しましょう。この 2 つのエージェントはほとんど同じで、一方はリサイクル・モードを使用し、もう一方はリサイクル・モードを使用しない点だけが異なります。非リサイクルのエージェントが完了するとき、Lotus Domino は、エージェントの完了ロジックのクリーンアップの部分で、使用済みのオブジェクトをエージェントに代わってリサイクルします。しかし、エージェントが終了するまではバックエンドのメモリは解放されないので、エージェントの実行時に使用されたメモリはこれよりもかなり大きくなります。

リサイクル・メソッドを持たないエージェント jMem_5000 のコードの一部を示します。

newDoc.appendItemValue("Form","JournalEntry");
newDoc.appendItemValue("Subject","removeme");
RichTextItem rti = newDoc.createRichTextItem("Body");
rti.appendText("lotsoftextgoeshere");
myArray[i] = newDoc; 
// ... //
depth = myArray.length;

リサイクル・メソッドを持つエージェント jrMem_5000 のコードの一部を示します。

newDoc.appendItemValue("Form","JournalEntry");
newDoc.appendItemValue("Subject","removeme");
RichTextItem rti = newDoc.createRichTextItem("Body");
rti.appendText("lotsoftextgoeshere");
myArray[i] = newDoc;
// ... //
myArray[i].recycle();
myArray[i] = null;
depth = myArray.length;

DDM 出力での各エージェントのメモリ・レポートは次のとおりです。

全文索引の操作

パフォーマンスの問題で、もう 1 つの一般的な原因として考えられるのが、全文索引が作成されていないデータベースでの全文検索の操作です。これらの操作が問題となる理由は、全文検索の操作を実行するときに、一時的な索引が作成されるからです。操作が終了すると、索引は削除されます。一致するキーワードに基づいて受信メールを各フォルダに振り分けるエージェントがあるとき、エージェントがメールメッセージを処理するたびに、一時的な索引が作成され、削除されます。会社のポリシーによってメールファイルに全文索引が作成されないケースでは、メールをソートするエージェントを持つユーザーがメールメッセージを受け取るたびに、この動作が繰り返し発生します。

エージェント内で全文検索を起動する方法は、次の 2 とおりがあります。

• 全文検索のメソッドを使用する。例: Set dc = db.FTSearch( query$, 0, _FT_SCORES, FT_STEMS)
• エージェントの [Document Selection] 領域で検索する用語を指定する。

選択条件で用語を選択する方法は、シンプルアクション・エージェントを含め、どのエージェントでも使用できます。シンプルアクション・エージェントは、プログラマーでないユーザーにもたいへんよく使用されています。多くのユーザーは選択条件が全文検索を起動することを知らないようなので、この記事ではこの点を強調しておきます。

Lotus Notes/Domino 6 では、この操作がパフォーマンスへの副作用を持つことを警告するメッセージがサーバーコンソールに表示されます。

01/18/2005 05:10:58 PM Agent Manager: Full text operations on database 'c:\notes_server\data\my\LS_Memory.nsf' which is not full text indexed. This is extremely inefficient.

Lotus Notes/Domino 7 では、DDM 調査を介して、全文索引が作成されていないデータベースで全文検索の操作を照合することにより、データベースごとに追加情報を得られます。これによって、どのデータベースで検索結果が最も多いのかがわかります。この追加情報は、全文索引を作成することが最も効果的なデータベースを判断するとき役立ちます。

上に戻る

エージェントと Web サービスのプロファイラー

問題の原因となっているエージェントを識別した後は、プロファイラーを使用してエージェントのコードを最適化できます。プロファイラーは、エージェントのロジック内の各メソッドの実行時間を測定するため、ボトルネックの発見に役立ちます。このツールによって、コード内の最も時間がかかる部分に注力でき、最大の効果を得られます。

プロファイラーは、Java および LotusScript におけるバックエンドのメソッドをプロファイルします。これは、Domino のバックエンド・メソッド、つまりバックエンド・オブジェクトへの操作 (例: dir.OpenDatabase("db.nsf")) をプロファイルするものであり、言語の標準コンストラクタ (例: Open fileName$) には作用しません。

エージェントをプロファイルするには、そのエージェントに対するエージェント・プロファイルをオンにする必要があります。この設定は、[エージェント] プロパティボックスの 2 番目のタブにあります。
。

プロファイル用のオプションをオンにすると、次回の実行時にエージェントがプロファイルされます。エージェントは、実行方法 (スケジュールに従って実行、Web エージェントとして実行、[アクション] メニューから手動で実行など) にかかわらずプロファイルできます。プロファイルした情報は、エージェントが置かれているデータベースのプロファイル文書に保存されます。

プロファイルした情報を表示するには、プロファイルしているエージェントを Domino Designer で選択し、[エージェント] - [View Profile Results] を選択します。この記事の例で使用したいくつかのエージェントのプロファイル出力を図 8、9、10 に示します。プロファイラーの出力の先頭に、エージェントの名前とプロファイルを実行した日時が表示されます。経過時間はエージェントの実行時間の合計で、その下に測定時間の合計が表示されます。この値は、表示用に切り捨てされるので、通常は若干小さな値になっています。たとえば、その下の表では、1 ミリ秒未満は 0 と表示されます。プロファイルの表には、クラス、メソッド、操作、メソッドへの呼び出し回数、およびメソッドの呼び出しに費やされた合計時間が含まれます。表内の情報は降順にソートされるので、最も時間のかかったメソッドが一番上に表示されます。

これらのプロファイラーの例を見るときは、次の点に注意してください。

どのケースでも、プロファイルされるコードは、サーバー上のメールファイルにアクセスし、すべてのデータベースのすべての文書のサイズを計算するよう設計されています。これはさまざまな方法で実現できる単純なタスクですが、説明用の例として適しています。私たちは、プロファイラーの能力を示すために、いくつかの方法でこのタスクをコーディングしました。
各エージェントのプロファイル出力を見ると、上位 1 つまたは 2 つのメソッドで、実行時間の合計の大部分を占めています。繰り返しごとの時間を得るには、時間を呼び出し回数で割る必要があります。この結果がコードの最適化に役立たないような場合もありますが、この例のように、文書のコレクションを取得する最も良い方法を示すこともあります。
この記事で前述したように、データへのアクセスを取得する方法として、set nvc = view.GetAllEntriesByKey を使用する方法が最もパフォーマンス的に優れています。

上に戻る

まとめ

パフォーマンスのチューニングは、絶え間ない技術的な挑戦であり、お客様からの増加する要求や期待に応えるための専門的な対策です。この連続記事で解説した情報、ヒント、そしてツールを、パフォーマンスの改善に役立てていただければ幸いです。

参考文献

• developerWorks Japan: Lotus: Lotusの日本の技術情報サイトです
  
  
• developerWorks: Lotus(US) : Lotusの英語の技術情報サイトです
  
  
• このシリーズのパート 1 『アプリケーション・パフォーマンスのトラブルシューティング: パート 1: トラブルシューティングの手法とコードのヒント』もお読みください。問題点を識別するための実証済みの方法や、ビューの索引とエージェントを最適化するために役立つヒントが解説されています。
  
  
• パフォーマンスに優れた Notes/Domino アプリケーションの作成方法については、developerWorks: Lotus 記事『アプリケーションのパフォーマンス・チューニング第1回』および『アプリケーションのパフォーマンスチューニング Part2』も参考になります。
  
  
• Domino アプリケーション (および、アプリケーションが実行されるサーバー) のパフォーマンスを改善する方法の詳細については、『Maximizing Domino Performance White Paper』を参照してください。
  
  
• Notes/Domino アプリケーションの作成方法の詳細については『Domino Designer ヘルプ』を参照してください。
  
  
• developerWorks ブログを通して developerWorks コミュニティに参加できます。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• はじめに
• アプリケーション・パフォーマンスのトラブルシューティング: データ収集用の新規ツール
• Domino Domain Monitoring でのアプリケーション調査
• アプリケーションの CPU使用量調査
• エージェントと Web サービスのプロファイラー
• まとめ
• 参考文献
• 著者について
• コメント