 |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Lotus Notes の大きなメール・ファイルに対するベスト・プラクティス
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dave Johnson, Software Engineer, IBM Joseph Peterson, Software Engineer, IBM レベル：中級 原文の掲載：2005年10月11日 更 新 日：2006年04月28日更新  原文はこちら
多くの企業では、社員が使用する Lotus Notes メール・ファイルのサイズが増加し続けていることを認識し、これらの大きなメール・ファイルに関するパフォーマンス・コストを制御する方法を模索しています。このため、IBM は大きくてアクティブなメール・ファイルの特性に関する研究を実施しました。これらのメール・ファイルには多数の文書と添付ファイルが含まれています。また、検索の頻度、全文索引の有無、メール文書の保管方法 (受信ボックスに残すか、分類するか) についての影響も調べました。 Lotus Domino への投資を最大限に活用する方法を理解するために、大きなメール・ファイルがさまざまな状態で実行されている Domino の特性を検証しました。テストには、異なるハードウェア・モデル、異なるオペレーティング・システム、Domino の複数のバージョン (Domino 5、Domino 6、Domino 7 のベータ・バージョン) を使用しました。この記事では、これらの結果を分析していきます。まず、大きなメール・ファイルがサーバー・パフォーマンスにどのような影響を与えるのかを示し、データベースと受信ボックスのサイズおよび全文索引のコストを削減するためのヒントを紹介します。そして、ユーザー、システム管理者、プランナーに、それぞれの立場に沿ったアイデアを提案します。 この記事で述べる推奨事項をテスト環境に導入すると、CPU のパフォーマンスが 30%以上改善されました。ただし、これらのテストはユーザーのワークロードのシミュレーションに基づくことに注意してください。ご使用になっている環境によっては、異なる結果が得られることがあります。この記事では、メール・データベースに焦点を当てていますが、ほとんどの推奨事項は他のデータベースにも適用できます。また、ベンチマーク・テストはさまざまな iSeries サーバーで実行されていますが、分析結果のほとんどは他のプラットフォームにもあてはまるでしょう。 この記事は、Notes/Domino に熟練していることを前提として書かれています。
テスト方法この記事で説明するテストには、複数の iSeries サーバー・モデルを使用しました。これらのサーバーには、830-2349 (8 Way 540MHz)、840-2461 (8 プロセッサー)、840-2461 (24 プロセッサー)、i5 POWER5 520 (2 Way)、550 (4 Way) などの各モデルが含まれます。また、Domino 5、Domino 6、Domino 7.0 (ベータ) コードを含む、さまざまな Domino バージョンをテストしました。記事の最後に記載されている推奨事項は、これらのすべてのリリースの Domino に適用されます。負荷は、最大 16クライアントを実行する Server.Load によって生成されました。このフリー・ツールは Domino Administrator クライアントに含まれています。また、テストの一部には NotesBench ツールが使用されています。選択したワークロードは、組み込みの R6 Mail Routing スクリプトです。このスクリプトは、多くの Domino メール・ユーザーの使用パターンに基づいています。各 PC では、500 〜 1000 ユーザーがシミュレートされました。Server.Load は、シミュレートされたユーザーが経験した平均応答時間をレポートします。すべてのケースで、サーバー上の負荷は応答時間が 1 秒を超えないレベルであり、一般的にはずっと低いレベルでした (最も重いユーザー・テストは、メール・ファイルが 2GB、すべてのメールが受信ボックスに含まれるケースで、このときの応答時間は 750ミリ秒です。最も軽いユーザーの応答時間は 11ミリ秒です)。 ほとんどのテストでは、1000人のユーザー・グループの各ユーザーが1秒ごとに新たにログオンしました。1000人全員がログオンするまでに約 17分かかります。次の 1000人のグループを開始するまでに、13分の休憩を取りました。実際の使用パターン (たとえば、月曜日の朝のピーク) では、もっと負荷が高まるでしょう。立ち上げ期間の後、各ワークロードを「安定状態」に少なくとも2時間保ちます。 実行時の変動を最小限にするために、それぞれの実行前に、すべてのメール・ファイルの新規コピーを作成しました。ほとんどのテストでは、すべての文書が 25KB のサイズとなるように、メール・ファイルが作成されています。この値は、IBM の内部ユーザーとさまざまなお客様の調査に基づくものです。これに対し、同じサイズのデータベースでも、文書数が少なく、各文書サイズが大きい場合は、CPU の使用度も低下します (詳しくは後述します)。 Server.Load および組み込みの NRPC Mail Initialization ワークロードを使用して、さまざまなサイズのメール・ファイルを作成しました。前述のように、ほとんどのテストでは、25KB の文書で構成されたメール・ファイルが使用され、文書数を 100 から 50,000 の範囲で変えています (これについては、後述します)。一部のテストではすべて同じサイズのファイル (たとえば、700MB) を使用しますが、受信ボックスに含まれる文書数は異なっています。また、含まれる文書数を一定に保ちながら、異なるサイズ (たとえば、400MB と 1GB) のメール・ファイルを使用するテストもあります。 システムのパフォーマンス・データは、iSeries Performance Tools (5722PT1) を使用してモニターしました。このツールは、CPU、ディスク、メモリー、ネットワークなどを含むシステム・リソースの使用状況をモニターします。
結果このセクションでは、テストの結果を考察します。これらのデータを調べるときは、文書サイズ、文書数、メール・ファイルのサイズ、受信ボックスに含まれる文書の割合といったメール・ファイルの特徴に注目してください。メール・ファイルのサイズ まず、メール・ファイルのサイズがパフォーマンスに与える影響から見ていきましょう。テストでは、文書数を増やすことで連続的にサイズを大きくしたメール・ファイルを作成しました。文書数の増加にともない、メール・ファイルのサイズが 20MB から 2000MB まで増加します (図1 参照)。 図1. メール・ファイルのサイズ  図 1 に示されるように、CPU の使用率の増加とファイル・サイズは、ほぼ直線に一致します (安定状態の CPU % およびピーク CPU % の両方で)。メール・ファイルは、すべて 25KB の文書で構成されています。 次の表は両方のテンプレートでのリソースの利用状況を示しています。最初の表は 6000擬似ユーザーでmail6.ntfテンプレートを利用した場合を示しています。 このテストに基づくと、大きなメール・ファイルは、特にユーザー・セッションの開始時とフェイルオーバー中に、より多くのメモリーを必要とすることがわかります。メール・ファイルのサイズを削減することにより、ビューの索引作成、圧縮、バックアップとリストア、トランザクション・ロギングのパフォーマンスが改善されます。この効果を測定するために、15MB から 2GB までのさまざまなサイズのメール・ファイルをテストしました。少なくとも 2GB のメール・ファイルまでは、ファイル・サイズが大きくなっても、安定状態の CPU で急激な上昇は見られませんでした。立ち上げ期間のピーク CPU は、安定状態の CPU よりも速いペースで上昇しますが、急激な上昇、あるいは鋭角的な変化は測定されませんでした。立ち上げ期間は、短時間に多くのユーザーがサインオンする状況 (たとえば、月曜日の朝やフェイルオーバー中など) をシミュレートします。たとえば、図 1では、メール・ファイルの平均サイズが 500MB から 1000MB に増加すると、安定状態では CPU が 12% 上昇しますが、立ち上げ期間では 55% も高くなります。これらのテストは、すべての文書が受信ボックス内にある状態で行われました。 受信ボックスの文書管理 次のテストでは、2000人のユーザーを 80分以上かけて開始し、その後、安定状態を 90分間保ちました。一方のテストでは、文書を受信ボックスに残し、もう一方のテストでは、受信ボックス内の文書数を、メール・ファイル全体の文書数の 25% までに制限しました。そして、2つのグループの CPU 使用率を時間をかけて比較しました (図2 参照)。 図2. 受信ボックスに文書を残したときの時系列の結果  受信ボックスに保存する文書数を全文書の 25% 以下に制限すると、すべての新規文書を受信ボックスに残す場合と比較し、ピーク CPU 使用率は 50% 、安定状態の CPU 使用率は 12% 低下することがわかりました。 次に、2つのユーザー・グループを使用して同様のテストを行いました。一方のグループでは各ユーザーの受信ボックスに 1000文書を含め、もう一方のグループでは各ユーザーの受信ボックスに 5000文書を含め、CPU の使用率を比較します。各グループのユーザー数は 5000 で、各ユーザーごとに索引と [すべての文書] ビューが構築されています。このテストの結果を図3 に示します。 図3. 受信ボックス内の文書数  図 3では、1組のグループが 400MB のメール・ファイルを使用し、もう 1組のグループが 1000MB のメール・ファイルを使用しています。どちらのケースも、受信ボックスを管理するための CPU の 低減率が 5% を超えています。次に、同じ 2組のグループでピーク CPU 使用率を比較してみましょう (図 4 参照)。 図4. ピーク CPU 使用率  図 4 に示されるように、受信ボックス内の文書数を最大 1000 までにとどめると、2 組のグループのどちらでも、ピーク CPU 使用率が大幅に低下します (400MB のメール・ファイルの場合は 72% に対して 50%、1000MB のメール・ファイルの場合は 75%に対して 62%)。受信ボックスのサイズを減らすことによるパフォーマンス面での利点は、安定状態の CPU よりもピーク CPU で顕著になります。 最後に、受信ボックス内の文書数を管理することが、応答時間にどれだけ効果があるのかを見ていきましょう (図 5 参照)。 図5. 応答時間  受信ボックス内の文書数を 1000 以下に抑えると、エンド・ユーザーに対する応答時間が飛躍的に速くなります。つまり、400MB のメール・ファイルでは 37ミリ秒に対して 23ミリ秒、1000MB のメール・ファイルでは 40ミリ秒に対して 24ミリ秒です。 これらのテストから、受信ボックス内の文書数を削減すると、ユーザーへの応答時間が改善されると共に、サーバーで必要となるリソース (CPU、メモリー、ディスク I/O、起動またはサーバーのフェイルオーバーの時間) も削減されることがわかりました。この効果は、「最初の操作」のときが最も高まります。受信ボックスを 75% 減少させると、立ち上げ時のスパイクがほぼなくなります。たとえば図 2 では、ピーク CPU は 50% 低下していますが、安定状態の CPU は 12% から 30% 改善されています。図 3、4、5 からわかるように、400MB のメール・ファイルの平均応答時間は、受信ボックスを 1000 文書以下に抑制したときよりも、2 倍 以上良い値になっています。 メール・ファイルのサイズの固定と混在 一般的なお客様のデータをシミュレートするために、メール・ファイルのサイズを混在させたテストも実施しました。しかし、結果的には、各テストの設定の難しさが報われるような大きな違いは得られませんでした。メール・ファイルのサイズが混在している場合は、立ち上げ時のピークがより先鋭になりますが、安定状態の CPU はほとんど同じでした (図 6 参照)。 図6. メール・ファイルのサイズの固定と混在  混在している状態とは、26MB から 2000MB までのメール・ファイルが含まれ、その平均サイズは 700MB です。メール・ファイルのサイズが混在している場合は、立ち上げ時はやや先鋭になりますが、安定状態ではほとんど同じです。 索引と検索 次に、全文索引と検索が CPU 使用率に与える影響について測定しました。検索のワークロードは、各ユーザーが 15分ごとに受信ボックスで検索を行う状況をシミュレートします。このテストの結果を図 7 に示します。 図7. 全文索引と検索  図からもわかるように、索引を維持するための CPU 消費は非常に小さいですが (このテストでは 1%)、検索の負荷は高く、CPU 使用率の 20% を占めています。 このテストに基づき、データベースを定期的に検索する場合は、一般的に全文索引を作成した方がよいという結論が得られました。全文索引を維持することは、パフォーマンスの観点からはコストが小さく、影響を少なくするためのオプションもたくさん用意されています。データベースの索引が作成されていないと、必要性が生じたときにサーバーによって「その場」で作成されることになります。これは非常に負荷がかかります。この動作を無効にするには、Notes.ini ファイルで「FT_FLY_INDEX_OFF=1」を設定します。 文書のサイズと数 メール文書のサイズと数が CPU 使用率に与える影響についてもテストしました。このテストでは、700MB のメール・ファイル持つ 2000人のユーザーがいる 2 つのグループを比較しました。2 つの違いは、メール・ファイルに含まれる文書のサイズと数です。一方のグループでは、メール・ファイルに各 25KB の文書が 28,000 個含まれ、もう一方のグループでは、各 100KB の文書が 7000個含まれています。このテストの結果を図 8 に示します。 図8. 文書のサイズと数  同じサイズのメール・ファイルでも、文書の平均サイズと文書数によって、消費するリソースが大きく異なる可能性があることがわかりました。このテストでは、メール・ファイル内の文書数が少ないグループの方が、メール文書数が多い (28,000) グループよりも、CPU リソースの消費量がかなり少なくなりました。 このテストは、メール・ファイル内の文書数、特に受信ボックス内の文書数が、ファイル・サイズ自体よりも、パフォーマンスに大きく影響することを示しています。もちろん、実際の使用状況に応じてこの 2 つの要因は変動します。とはいえ、メール・ファイルのサイズが一定だとすると、小さな文書がたくさんあるユーザーの方が、サイズが大きく文書数が少ないユーザーよりも多くのリソースを消費する結果が得られています。 Domino パーティション 最後に、ユーザー数を一定にして、Domino パーティションの数による CPU 使用率の違いを比較しました。結果を下表にまとめます。
表に示したパフォーマンス情報は Domino 7 のベータ・バージョンを使用して収集したもので、変更される可能性があります。Domino 7 でのパフォーマンスの強化により、1 つの Domino パーティションでサポートできるユーザー数が Domino 6 よりも増加しています。このデータは、5 時間にわたる安定状態での平均の使用率と応答時間を表しています。単一の Domino パーティションの CPU 使用率が、パーティション数が 2 〜 4 の場合よりも明らかに低下していることに注目してください。メモリーおよびディスク統計も、Domino パーティションが少ないほど、必要なメモリーが減少する傾向を示しています。応答時間の 1 ミリ秒のわずかな違いは知覚できるものでなく、測定誤差の範囲です。単一パーティションでメモリーおよびディスク統計が改善されているにもかかわらず、応答時間が短縮されていない事実は、1 つのパーティションに過剰なユーザーがいるために余分な競合が発生した可能性を示しています。 新しい各サーバーには、追加のシステム・リソースが必要です。メッセージが異なるサーバーに置かれる可能性が高いので、メール配信に時間がかかる傾向になります。Domino 7 は、すべてのプラットフォームに対してスケーラビリティーが大幅に改善されているので、1 つの Domino Server でより多くのユーザーをサポートできます。このテストでは、4 つのサーバーのユーザーを 1 つのサーバーにまとめると、CPU 全体のパフォーマンスが 10% 向上し、メモリーの消費が減少します。
推奨事項これらのテスト結果に基づき、Domino メールのパフォーマンスを改善するいくつかの推奨事項を説明します。Domino パフォーマンスを改善する最も簡単な方法の 1 つは、受信ボックスを管理することです。テストによると、受信ボックスのサイズを減らす (同じメール・ファイル内の他のフォルダにメールを分類する) と、エンド・ユーザーへの応答時間、サーバーでの安定状態の CPU、および、特にピーク CPU が向上します。この場合のピーク CPU は、ユーザーが最初にメール・ファイルを開く状況に関連します (次が、セッションのタイムアウト)。このため、ユーザーには、受信ボックスから他のフォルダに文書を移し、受信ボックスのサイズをできるだけ小さく保つよう ( 1000 文書未満が望ましい) アドバイスしてください。これによって、応答時間が短くなるだけでなく、リソースの使用率も改善されます。また、受信ボックスのサイズを自動的に「調整」するエージェントを作成することもできます。たとえば、このサンプル・ファイル (US)には、受信ボックスから古い文書を削除するサンプル・エージェントのコードが含まれています (削除された文書は [すべての文書] ビューで使用できます)。エージェントは、勤務時間外 (たとえば、週末など) に定期的に実行するよう設定できます。受信ボックスの管理に加え、その他のヒントを Notes ユーザー、Domino システム管理者、システム・プランナー別に説明します。 Notes メールのユーザー Notes メールのユーザー用の推奨事項は次のとおりです。
Domino のシステム管理者 システム管理者のメール管理を支援するオプションは多数用意されています。
システム・プランナー 大規模な Domino 環境をサイジングすることは複雑なプロセスになりがちです。このような環境では、さまざまなワークロード特性とその相互関係により、パフォーマンスへの影響が増幅します。私たちの研究に基づくと、次のような特性を 1 つでも持つ Domino iSeries 環境を計画およびサイジングする場合は、IBM/Lotus に問い合わせることをお勧めします。
まとめこの記事で解説したテスト・データと推奨事項がお役に立つことを願っています。もちろん、メールは Notes/Domino で最も良く使用され、最も重要な機能の 1 つです。メール・ユーザーに優れたパフォーマンスを提供することは、Notes コミュニティーのすべてのユーザーを幸せにするだけでなく、システム管理者自身の仕事を削減することにもつながります。
リソース
筆者について（原文のまま）Dave Johnson is currently a member of the iSeries System Performance area with a focus on Domino performance. Dave's team is also responsible for NotesBench audits for IBM eServer iSeries.Joseph H. Peterson is on the iSeries development team in Rochester Minnesota. His focus is on performance of Lotus products.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
