アイテム数の多さと制限付きビューがパフォーマンスに与える影響について

  • [アーティクル]

 

トピックの最終更新日: 2009-01-14

ここでの説明は、オンライン モードで実行されている Microsoft Office Outlook、代理アクセスによるキャッシュ モードの Outlook、および Outlook Web Access を使用している場合に、重要なパス フォルダ内のアイテム数の多さや制限付きビューの要求に関連した、Microsoft Exchange Server 2007 のパフォーマンスの問題を理解、診断、解決するために役立ちます。重要なパス フォルダとは、予定表、連絡先、受信トレイ、および送信済みアイテム フォルダのことです。制限付きビューとは、検索条件に基づいて情報が制限され、フォルダ内のアイテムのサブセットのみが表示されるデータ ビューのことです。多くの場合、これらの状況についてのパフォーマンスの問題は、関連性が高く、クライアント アクセスの遅さという目に見える形でエンドユーザーに認識されます。重要なパス フォルダ内のアイテム数が異常に多くなっているユーザーが数人いるだけで、Exchange 組織全体で認識されるパフォーマンスの問題の原因となります。

Exchange Server 2003 では、推奨されるフォルダあたりの最大アイテム数は 5,000 でした。Exchange 2007 では、I/O の改善、ページ サイズの増大、およびキャッシュの増加により、推奨される最大アイテム数を増やすことができるようになりました。ハードウェアが正しく設計されていれば、20,000 ものアイテム数でも、ユーザーの操作性を許容範囲内に維持できます。

note注 :
一般的な操作では、クリックからアクションまでの応答時間が 100 ミリ秒以内であれば、ユーザーの操作性は許容範囲内にあると言えます。新しい並べ替え順序の作成や初回のフォルダの選択など、使用頻度の低い操作の場合は、1 分以内の応答時間は許容範囲です。

この推奨される最大値は、サード パーティのプログラムがユーザーのメールボックスにアクセスするかどうかによって変化します。このようなサード パーティのプログラムには、次のようなプログラムがあります。

  • Outlook アドイン
  • 電子メールのアーカイブ
  • ウイルス対策
  • モバイル デバイス
  • ボイス メール
  • 追加のビューや検索フォルダを作成するその他のプログラムや Outlook アドイン

このような場合、サーバー全体の負荷と共に、サーバーが特定のサード パーティのプログラムからの各要求をどのように処理するかを検討して、アイテム数を決定する必要があります。

この推奨される最大値は、Exchange 環境の処理能力によって異なります。ハードウェアの選択によっては、最大数が小さくなる可能性があります。受信トレイ フォルダと送信済みアイテム フォルダのアイテム数を 20,000 未満に、連絡先および予定表のアイテム数を 5,000 未満に抑えることをお勧めします。推奨される最大値未満にアイテム数を抑えた場合でも、操作によっては依然として大幅に時間がかかる場合があります (通常、これは約 1 分です)。このような操作には、新しく並べ替えの順序を指定する場合や、初めてフォルダを選択するなどの操作があります。フォルダのビューを初めて表示する場合、ビューの生成にさらに時間がかかる可能性があります。重要なパス フォルダ内のアイテム数が多くなると、サーバーのパフォーマンスが低下する可能性があります。これは、ユーザーのメールボックスの中で最も頻繁にアクセスされるのがこれらのフォルダであるためです。その他のフォルダ (特に、エンドユーザーによって作成されるカスタム フォルダなど) は、アクセス頻度が高くないため、ユーザーの操作性を低下させることなく、大量のアイテムを処理できます。アクセス頻度がそれほど高くないフォルダの場合は、このフォルダ内のアイテム数が多くなった場合でもパフォーマンスへの影響は大きくありません。ただし、これらのフォルダ内のアイテム数が多くなると (このようなフォルダの数が増えたり、サーバー上のアクティブ ユーザー数が増えると)、断続的なパフォーマンスの問題が発生する可能性があることに注意してください。

important重要 :
フォルダのビューを初めて表示する場合、ビューの生成にさらに時間がかかる可能性があります。したがって、メールボックスの移動操作を行うと、アイテム数が多いすべてのフォルダで初めてビューを表示する際のパフォーマンスが低下します。このため、新しいサーバーに移動したユーザーが自身のフォルダにアクセスし、フォルダ ビューを再作成する際に、断続的なパフォーマンスの問題が発生する可能性があります。移動を複数のサーバーに分散し、同じサーバーに同時に移動するメールボックス数を少なくすることによって、メールボックスの移動に関する運用面でのベスト プラクティスに従えば、この問題を最小限に抑えることができます。

組織に適した最大アイテム数を検討する場合、最大値を超えてもパフォーマンスが急激に低下するわけではないが、少しずつパフォーマンスが低下していくことを理解しておいてください。指定した制限値は固定されません。この制限値は、テストとコード分析に基づいた数値になります。アイテム数が増加していくと、パフォーマンスはユーザーが感知するレベルまで低下する可能性があります。環境でユーザーが許容できるパフォーマンスのレベルによって、その環境に適した最大アイテム数が決まります。

個々のメールボックスに固有のサイズ制限はないことを理解しておく必要があります。メールボックス サイズを制限する主な要因には、ディスクの空き領域、バックアップおよび復元時間、サービス レベル契約、および Outlook のパフォーマンスがあります。Outlook のパフォーマンスとは、具体的にはエンド ユーザーの待機時間を指します。

ハードウェアの選択がパフォーマンスに与える影響について

繰り返しますが、組織のハードウェアの規模が適切ではない場合、アイテム数が少なくてもパフォーマンスが低下する可能性があります。オンライン モードでは、メールボックス内のアイテム数の増加によってシステムの I/O 要件が増大します。ディスクの待機時間は、アイテム数の多さに関連したハードウェア パフォーマンスを評価する際の、最も重要なハードウェアに関する考慮事項の 1 つです。最適なユーザー操作性のために、サーバーのピーク利用時間中でも、ディスクの待機時間が少なくなるよう (20 ミリ秒以下) にする必要があります。

どのようにディスクの待機時間が合計され、サーバーのパフォーマンスに影響が及ぶのかを示すために、次の例について考えてみます。ビューを要求する場合、データの要求は一括操作ではなく、ディスクから個々のシリアル化された要求で実行されます。たとえば、プラグインが 1,000 アイテムのビューを返しているとき、Exchange ストアは、(要求ごとに約 5 個のメッセージが取得されると仮定して) 約 200 件のデータ要求を行う可能性があります。20 ミリ秒で、ディスク サブシステムだけで 4 秒の遅れが生じます。ディスクの待機時間が 50 ミリ秒または 100 ミリ秒まで増えた場合のパフォーマンスに及ぶ影響の大きさについて考えてみます。同様の要求を行うために複数のプラグインが使用されている場合、問題はさらに悪化します。この場合、Outlook が頻繁にブロックされるようになる可能性があります。

Exchange 2007 の良好なパフォーマンスを確保するためのサーバーのサイジングに関する推奨事項の詳細については、「サーバーおよびストレージ アーキテクチャの計画」を参照してください。

追加の処理時間が必要になる場合がある理由について

サーバーの処理能力に対するアイテム数の多さと制限付きビューの要求がパフォーマンスに与える影響を考える場合、発生する基本的なプロセスと、アイテム数の多さおよび制限付きビューの要求がこれらのプロセスとどのように関連しているのかを確認する必要があります。

フォルダの内容は、インフォメーション ストア データベース内のテーブルに格納されます。アイテム数が増加するにつれて、格納域の複雑さも増します。Exchange ストアのストレージ メカニズムは、Extensible Storage Engine (ESE) です。ESE は、B+ ツリー データ構造を使用してレコードを格納します。レコード数が増すにつれて、情報を検索し、B+ ツリーを通過するために必要になる可能性のあるディスク I/O 要求の数も増加します。詳細については、「Extensible Storage Engine のアーキテクチャ」を参照してください。

アイテム数が増加すると、要求されたデータがハード ディスク上の物理的に隣接した場所に配置される可能性が大幅に減少します。このため、より多くの I/O 要求が必要になります。

制限付きビューの作成には、Exchange サーバーからの処理が必要になります。

MAPI でメッセージをフィルタ処理するには、2 つの方法があります。

  • 検索フォルダ

検索フォルダは標準的な MAPI フォルダに似ています。ただし、メッセージの代わりに、検索フォルダには他のフォルダ内のメッセージへのリンクのみが格納されます。これらのメッセージは、指定された制限を満たすメッセージです。
  • 制限
    制限は、MAPI テーブルで IMAPITable::Restrict メソッドを呼び出すことによって作成されます。結果のテーブルには、指定された制限に一致するアイテムのみが表示されます。制限された内容のテーブルには、1 つのフォルダのメッセージのみが表示されます。この種類の制限は、検索フォルダのフィルだ条件を記述する MAPI 定義の構造と混同される場合があります。このような MAPI 定義の構造も制限と呼ばれます。

検索フォルダおよび制限を使用すると、追加の処理が必要になります。たとえば、検索フォルダを作成する処理や、ユーザーの条件を満たすアイテムを検索フォルダに格納する処理です。この処理では、フォルダ内の各アイテムを調べ、各アイテムを検索フォルダに入れるのかどうかを決定する必要があります。したがって、フォルダに多数のアイテムが含まれている場合、ビューの作成に要する時間は長くなります。これらの検索フォルダは、検索が開始された各フォルダの下に SearchFID として格納されます。既定では、検索フォルダは作成されてから最大で 40 日間存在します。

制限付きビューの存在は、フォルダ内のアイテムへの変更が適用される速さに影響します。検索フォルダがあるフォルダに関連付けられると、別のフォルダのアイテムが追加、削除、または更新される際に、より多くの処理が発生します。この処理は、Exchange で検索フォルダを更新するのかどうかを判断する必要があるために生じます。多くの検索フォルダを作成すると、各変更がすべての検索フォルダに対して評価され、それぞれの検索フォルダを更新する必要があるかどうかが判断されます。

より多くの標準以外のプロパティが Outlook のフォルダ ビューに追加される場合、標準以外のプロパティを Exchange ストアから取得するには、追加のリモート プロシージャ コール (RPC) が必要になります。フォルダに多くのアイテムが含まれている場合、Exchange サーバーからデータを取得するためにより多くのラウンド トリップが必要になります。

予定表フォルダを表示する場合、Outlook では、指定したデータ範囲内のすべての予定を見つける必要があります。このため、少なくとも 2 つの処理要求が必要です。最初の要求では、指定した日付の範囲内のすべての静的な予定を取得します。2 つ目の要求では、指定した日付の範囲内に発生する定期的な予定をすべて検索します。2 つ目の要求を処理するために必要とされる時間は、予定表フォルダ内にあるアイテムの数に比例します。この理由は、Outlook がすべての定期的な予定を要求するためです。定期的な予定の一覧が取得された後で、それぞれの定期的な予定を調べ、その予定が指定した日付の範囲内に発生するのかどうかを確認する必要があります。予定表に多くのアイテムが含まれている場合、これらの要求を処理するのに要する時間は長くなります。

アイテム数とメールボックス サイズがパフォーマンスに与える影響について

パフォーマンスに関する問題の多くは、サイズが大きいメールボックス (2 GB 以上のメールボックス) によるものではなく、サーバー上でアクセスされる 1 つまたは複数のフォルダ内のアイテム数が多いために発生することを理解しておく必要があります。フォルダ内に多数のアイテムがあると、フォルダ内での処理に要する時間が長くなるため、パフォーマンスが低下します。特に、予定表、連絡先、受信トレイ、および送信済みアイテム フォルダという重要なパス フォルダ内のアイテム数によって、パフォーマンスは大きな影響を受けます。サイズの大きいメールボックスを計画する方法の詳細については、「White Paper: Planning for Large Mailboxes with Exchange 2007」を参照してください。

フォルダ内のアイテム数によって異なる操作には、ビューに対する新しい列の追加、新しい列での並べ替え、および検索があります。多くの Outlook プラグインは実行時に並べ替えまたは検索を行いますが、これらの要求は他の Outlook MAPI 要求と重複する場合があります。これにより、ユーザーの操作性が低下します。

キャッシュ モード (Outlook 2003 以降の既定のモード) で実行している場合、フォルダ内のアイテム数が増加すると、クライアントのパフォーマンスに関する問題が発生する可能性があります。1 つ実行する必要があるとするば、それは OST ファイル (ローカル データ キャッシュ) に断片がない状態を保つことです。このためには、Windows SysInternals ツールである Contig を使用できます。最新バージョンの Contig をダウンロードするには、「Contig v1.55」 (英語) を参照してください。

重要なパス フォルダ内のアイテム数に加え、ユーザーのコンピュータで実行される他の MAPI アプリケーションや Outlook プラグインの数など、アイテム数の多さによって悪化する Outlook の操作性に影響を及ぼすその他の要因があります。すべての MAPI 要求には、emsmdb32.dll による処理時間が必要です。要求を行っているプラグインの数が多い場合、Outlook の実行速度は遅くなり、サーバーに及ぶ影響が大きくなる場合があります。さらに、要求された操作の複雑さが影響を及ぼします。たとえば、フォルダ内のすべてのアイテムを開封済みとしてマークすると、1 つのアイテムをマークする場合よりも長い時間がかかります。長い時間がかかる可能性のあるその他の操作には、会議出席依頼に関して多数のユーザーの空き時間情報を取得したり、複数のフォルダにわたる検索を実行したりする操作があります。ユーザーが頻繁に複雑な操作を実行する場合、多数の Outlook プラグインを使用している場合、または連絡先フォルダと予定表フォルダの利用頻度が高い場合、アイテム数の増加によってパフォーマンスが低下する可能性が大幅に高くなります。

制限付きビューについて (MAPI 制限)

MAPI は、通常、テーブルの形式でデータを表します。プロバイダの一覧、フォルダ用のテーブル、フォルダの内容、添付ファイルなどを要求された場合に、クライアントに対して表示されるテーブルがあります。各テーブルは列で構成されます。各列は、送信者、件名、配信時間などの属性を表す、異なる MAPI プロパティです。各列は、特定のアイテムを表します。フォルダの内容のテーブルの場合、各行はメッセージを表します。これらのテーブルに対するクライアントの操作は、データの並べ替えなどの処理によって表されます。クライアントは、指定した条件と一致する特定の行に対してテーブル内をシークできます。この操作は FindRow() と呼ばれます。特定の条件に合うアイテムのみをテーブルに含めるように要求することもできます。特定の日に作成されたアイテムのみを含める例を示します。これは、制限と呼ばれます。結果として作成されるフォルダの内容のテーブルには、指定した条件と一致するテーブル内のアイテムのみが含まれます。制限は、クライアントが頻繁に同じデータ表示形式を要求すると予想される場合に使用されます。

制限付きビューがパフォーマンスに与える影響

制限がパフォーマンスに与える影響を理解するには、MAPI クライアントによって要求されたデータをインフォメーション ストアが実際に格納し、FindRow、Restrict などの要求を解釈する方法を考慮する必要があります。ストアのストレージ スキーマ内には、メールボックス、フォルダ、フォルダの内容、およびメッセージなどをまとめて表すさまざまなテーブルがあります。

クライアントがフォルダの内容の一覧を要求した場合、その要求は MessageFolder テーブル (MsgFolder) と呼ばれる特別なフォルダにマップされます。システム内で作成される各フォルダには、個別のメッセージ フォルダ テーブルがあります。MsgFolder テーブルの目的は、フォルダをその内容にマップすることです。

Restrict の呼び出し (頻繁な同じデータの再要求) の期待値を処理するために、新しい特別なフォルダ (および対応する MsgFolder テーブル) が作成されます。このフォルダは、制限付き検索フォルダと呼ばれます。このフォルダは元のフォルダにリンクし直され、これらの 2 つのフォルダ間には論理的な関係が存在するようになります。制限によって指定される条件を満たすアイテムのみが含まれるように、条件が検索フォルダに適用されます。この検索フォルダ内には、制限の条件を満たす MsgFolder テーブル内にある各メッセージの、MsgFolder テーブル内の元の行へのバックリンクが存在します。

この動作によって発生するパフォーマンスの問題は、各検索フォルダに対する更新を管理するために必要になる時間です。元のフォルダで変更が生じると、変更は、対象となるフォルダに関連付けられているそれぞれの制限付き検索フォルダと比較され、更新する必要があるかどうかが判断されます。1 つまたは多数のフォルダ用に大量の検索フォルダが存在する場合、その影響はより大きくなります。発生する 2 つ目の問題は、制限付き検索フォルダの作成です。制限付き検索フォルダを作成するには、制限付き検索フォルダにリンクする必要のある個々のアイテムを抽出するために、元のフォルダでの完全な処理が必要になります。クライアント操作の直接の結果としてこの処理が実行された場合、時間の遅延により、ハングが起きたり、要求を処理するのに長時間かかっていることを示す Outlook RPC ポップアップ ボックスが表示されたりする場合があります。制限付き検索フォルダを作成するために必要になる時間は、通常のフォルダ内にあるアイテムの数に比例します。フォルダ内のアイテム数が増加するにつれ、これらのアイテムが隣接したディスク セクタに配置される可能性が大幅に減少します。これにより、アイテム数の多いフォルダで制限付きビューの要求を満たす際には、ランダム ディスク I/O が大幅に増加します。アイテム数の多いフォルダで制限付きビューの要求数が増加すると、サーバー上でリソースにアクセスするすべてのユーザーが、I/O に対する影響が大きくなっていることを認識するようになります。

Exchange 2000 Server、Exchange Server 2003、および Exchange Server 2007 では、フォルダごとに許可される制限付き検索フォルダの最大数があります。既定の最大数は 11 です。検索フォルダの既定の有効期間は 40 日です。

制限付き検索フォルダは、先入れ先出し (FIFO) ベースで処理されます。あるフォルダに対して 11 個の制限付き検索フォルダが既に関連付けられており、新しい Restrict 要求が行われている場合、実際に使用された前回の制限を使用して、検索フォルダの一覧が評価されます。つまり、新しい要求を処理できるように、使用頻度の低い制限付き検索フォルダは削除されます。前に説明したように、この要求によって通常の MsgFolder テーブルの完全な処理が必要になり、クライアントによって直接操作が行われる場合、テーブルが構築されて、クライアントに対して表示される間に、クライアントでパフォーマンスの問題が発生する可能性があります。このため、毎日または毎週、12 個以上の制限付き検索フォルダが必要になる可能性があります。この結果、現時点で一致する検索フォルダが存在しない Restrict 要求がクライアントで発生します。続いてそのフォルダが削除され、新しい制限付き検索フォルダが作成されることになります。これらの要求はすべて連続的に処理されます。つまり、多数のユーザーが、制限付きビューが定期的に要求されるフォルダ内に非常に多いアイテム数を持っている場合、これらの要求はキューに置かれる可能性があります。これにより、そのサーバーをホーム サーバーとするメールボックス データにアクセスするすべてのユーザーによって全体的に認識されるような遅延が発生します。この影響は、メールボックスにアクセスするユーザー以外にも及ぶことを理解しておく必要があります。たとえば、サーバーに格納されている予定表データにアクセスする他のサーバー上のユーザーも遅延を認識するようになります。

important重要 :
追加のロケールをクライアント側にインストールすると、Outlook Web Access とオンライン モードの Outlook のユーザーのビューがさらに多く作成される可能性があります。

制限付きビューと共有の予定表

他のユーザーの予定表、連絡先フォルダなどを表示すると、フォルダが表示されるまでに遅れが生じる場合があります。フォルダが表示されると、切り替えは非常に迅速に行われます。ただし、しばらくすると、フォルダへのアクセスに時間がかかるようになります。予定表内のアイテム数が 5,000 を超えると、待機時間は特に長くなります。

Outlook で他のユーザーのフォルダにアクセスする場合、ユーザーが非公開アイテムを表示できないように制限するビューが適用されます。

フォルダのビューを適用する処理では、ストア内に検索フォルダが作成されます。検索フォルダが作成されると、後で使用するためにキャッシュされます。ユーザーが既に存在する検索フォルダを作成しようとした場合、キャッシュされた検索フォルダが使用されます。このため、それ以降の表示は非常に迅速になります。

既定では、すべての検索フォルダが無期限にキャッシュされることはありません。キャッシュする検索フォルダの数が多すぎると、サーバー側で、検索フォルダの更新に関連した遅延が生じます。一方、十分な数の検索フォルダがキャッシュされないと、検索フォルダを生成して更新する必要があるために、同様の問題が発生することになります。

この問題について示すために、フォルダごとに 11 個の検索フォルダ (ビュー) を保持するように Exchange サーバーが構成されているシナリオを考えてみます。Frank が他のユーザー 15 人と共有している予定表フォルダがあるとします。Sally はフォルダにアクセスし、検索フォルダの構築時に遅延を経験します。検索フォルダの構築後、アクセスは迅速になります。その後、Sally はフォルダを 1 日表示しておらず、他の 11 人のユーザーはフォルダにアクセスしています。各ユーザー用に新しい検索フォルダが構築されます。キャッシュされる検索フォルダは 11 個のみであるため、12 人目のユーザーによりフォルダがアクセスされると、Sally 用に構築されたフォルダは削除されます。次回 Sally がフォルダをアクセスする際には、検索フォルダが構築されるまで待つ必要があります。

今度は、20 個のビューをキャッシュするように、Frank のメールボックス サーバーを構成するとします。その結果、Sally と他の 14 人のユーザーは Frank の予定表フォルダにアクセスでき、15 個の検索フォルダのみが作成されます。15 は 20 よりも少ないため、ビューを循環させる必要がありません。このため、最初のアクセスによって検索フォルダが作成されてからは、すべてのユーザーのアクセスが迅速になります。

キャッシュされる検索フォルダの既定の数は 11 です。この構成は、データベース レベルで設定されます。構成済みの値は、ADSIEdit を使用して表示できます。ADSIEdit を使用して、Store オブジェクトを表示し、msExchMaxCachedViews 属性を調べます。識別名は次のとおりです。

CN=Database, CN=Storage Group,CN=InformationStore,CN=Server NAME,CN=Servers,CN=AG Name,CN=Administrative Groups,CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com

場合によっては、値を 11 より大きな値に変更することは、環境におけるパフォーマンスの影響を調整するのに役立ちます。

important重要 :
msExchMaxCachedViews 属性値は、50 よりも高い値に設定しないでください。
important重要 :
環境に Outlook 2003 RTM が存在している場合、共有の予定表を操作する際のパフォーマンスの低下に関する既知の問題に対処するため、Service Pack 1 以降が展開されていることを確認してください。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。