メモリ制約の問題を排除する

Exchange Server は、その仕様によりメモリを頻繁に使用し、最大 3 GB までの物理メモリを使用することができます。運用サーバーでは、Store.exe プロセスは大量のメモリ キャッシュを維持するため、通常 1.5 GB の仮想メモリを使用します。

Exchange 内のさまざまなプロセスによるメモリの使用に加えて、Exchange の ExIFS カーネル ドライバも、カーネル メモリを使用します。ユーザーにはあまり認識されませんが、カーネル メモリの使用率が高いと、パフォーマンスが大幅に低下し、動作が不安定になります。

ユーザー領域のメモリを調べる

サーバーがメモリを使用し、空きメモリが残り少なくなると、オペレーティング システムはプロセスのワーキング セットを縮小し、ページ ファイルをより多く使用し始めます。ディスク操作はメモリ操作よりも時間がかかるため、ページ ファイルを使用すると全体的なパフォーマンスが影響を受けます。

また、ディスクとのページングが頻繁になると、最終的にディスクのボトルネックが発生し、パフォーマンスに悪影響を及ぼします。この場合は、実際の問題はメモリで、ディスクのボトルネックは症状であるに過ぎません。

次の表に示すカウンタを使用して、ユーザー領域のメモリの現在の状態を判別できます。

ユーザー領域のメモリのパフォーマンス カウンタ

ユーザー領域のメモリを向上させる

次の一覧では、ユーザー領域のメモリのパフォーマンスを向上する方法を示しています。

• 余分なソフトウェアを削除する
  Exchange で使用するリソースを解放するために、リモート監視を行うサード パーティ製ソフトウェア ツールや他の必要ないサービスをサーバーから削除します。パフォーマンス スナップインを使用すると、各アプリケーションがどれだけのメモリを消費しているかを理解できます。
• ピーク時間を避けて保守タスクを実行する
  保守ツール (Eseutil など) やタスク (メールボックス管理など) をピーク時間に実行すると、Exchange で必要とされるメモリが消費されます。これらのツールおよびタスクを、ピーク時間を避けて、または使用率が低い時間帯 (週末など) に実行することが適切です。

カーネル メモリの使用率を調べる

中核的なオペレーティング システム、つまりカーネルで使用されるいくつかのメモリ構造で構成される Windows カーネル メモリは、Exchange Server が正常に展開されるようにするために監視する必要のある別の領域です。ここでは、Exchange サーバーのパフォーマンスと信頼性に影響するカーネル メモリ構造を、監視およびトラブルシューティングする方法について説明します。

次の 3 つの主要なカーネル メモリ構造を、Exchange を実行しているサーバー上で監視する必要があります。

• ページ プール ページ プールは、ディスク ページング ファイルにページングできる共有システム メモリの一部です。ページ プールは、システムの初期化時に作成され、システム メモリを割り当てるためにカーネル モード コンポーネントにより使用されます。
• 非ページ プール 非ページ プールは、常に物理メモリ中に存在していることが保証されているシステムの仮想アドレスで構成されるため、ページの入出力 (I/O) を伴わずに、任意のアドレス スペースからアクセスすることができます。ページ プールと同様に、非ページ プールもシステムの初期化時に作成され、システム メモリを割り当てるためにカーネル モード コンポーネントにより使用されます。
• システム PTE ページング ファイルの仮想メモリ アドレスは、ページ テーブルによって物理メモリ アドレスにマップされます。Microsoft Exchange Server 2003 では、システムのページ テーブル エントリ (PTE) のプールを使用して、I/O スペース、カーネル スタック、およびメモリ記述子一覧などのシステム ページをマップします。

Boot.ini ファイル設定によるカーネル メモリ空間のサイズへの影響

Exchange サーバーでのカーネル メモリ空間の最大サイズは、Microsoft Windows Server™ 2003 boot.ini ファイルの設定によって影響を受けることがあります。たとえば、boot.ini ファイルで /3GB スイッチを使用する場合、ユーザー モード プロセスに 3 GB の仮想アドレス スペースが割り当てられ、1 GB の仮想アドレス スペースのみがオペレーティング システムに割り当てられます。

/3GB スイッチの詳細については、以下のマイクロソフト サポート技術情報の文書を参照してください。

• 文書番号 823440「Windows Server 2003 ベースのシステム上の Exchange Server 2003 での /3GB スイッチの使用」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=823440)
• 文書番号 316739「/userva スイッチと /3GB スイッチを使用してユーザー モード領域を 2 ～ 3 GB の間でチューニングする方法」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

次の表は、Exchange を実行しているサーバー上の各カーネル メモリ空間のおおよその最大サイズが、boot.ini 設定によってどのように異なるかを示しています。この例では、Exchange Server 2003 は、4 GB の RAM を持つ Windows Server 2003 を実行するマルチプロセッサ サーバーで実行されています。

Boot.ini 設定と最大カーネル メモリ空間のサイズ

次の表は、4 GB の RAM を持ち、Windows Server 2003 を実行するマルチプロセッサ サーバー上で実行される Exchange Server のパフォーマンス モニタの警告設定を示しています。"警告" レベルでは、サーバーは安定していますが、メモリ リークの可能性があるため、メモリ割り当てを調査する必要があります。"重大" レベルの場合、特に負荷のスパイクにおいて、サーバーが不安定になる危険性があります。

異なる Boot.ini ファイル設定によるパフォーマンス モニタの警告設定

* パフォーマンス モニタの "Memory\Free System Page Table Entries" カウンタは、Service Pack 1 なしでインストールした Windows Server 2003 上では不正確になります。このカウンタの詳細については、マイクロソフト サポート技術情報の文書番号 894067「パフォーマンス ツールは、Windows Server 2003 に利用可能な空きシステム ページ テーブル エントリを正確に示しません。」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=894067) を参照してください。

Exchange を実行するサーバーのカーネル メモリ枯渇の症状

Exchange を実行するサーバーのカーネル メモリ枯渇の症状は、応答速度の低下から、明らかなエラーまでさまざまです。

Exchange を実行するサーバーのカーネル メモリ枯渇の症状

Exchange を実行するサーバーのカーネル メモリのトラブルシューティング

前述の「異なる Boot.ini ファイル設定によるパフォーマンス モニタの警告設定」の表に示したパフォーマンス モニタのカーネル メモリ カウンタが推奨される値の範囲外であるか、「Exchange を実行するサーバーのカーネル メモリ枯渇の症状」の表で説明した症状が観察される場合、次のトラブルシューティング方法を使って、カーネル メモリの枯渇の原因を判別してください。

1. Microsoft Exchange Server ベスト プラクティス アナライザ ツールを実行して、Exchange サーバーが正しく構成されているかどうかを判断します。
   Exchange Server カーネル メモリ空間に影響を及ぼすさまざまな構成設定があります (たとえば、前述の /3GB および /Userva boot.ini 設定、SystemPages レジストリ キーなど)。カーネル メモリ枯渇の症状を調べる前に、サーバーのカーネル メモリが正しく構成されていることを確認するのは非常に重要です。Microsoft Exchange ベスト プラクティス アナライザ ツールを実行し、その出力結果を注意深く参照してサーバー構成が正しいことを確認します。ツールの詳細については、Microsoft ダウンロード センターの Exchange Server ベスト プラクティス アナライザ ツールについてのページを参照してください (このサイトは英語の場合があります)。
2. どのカーネル メモリ空間が枯渇しているかを判別します。
   • イベントを分析する ページ プールおよび非ページ プールの割り当てエラー イベントの証拠としてイベント ビューアのログを分析します (イベント ID 2019 および 2020)。
   • パフォーマンスを分析する パフォーマンス モニタを使用して、24 時間の間、60 秒ごとに計測されたサンプルで、ページ プール、非ページ プール、および空きシステム PTE のログを作成します。パフォーマンス モニタのログの結果を、前述の「異なる Boot.ini ファイル設定によるパフォーマンス モニタの警告設定」の表で示された警告トリガおよび重大トリガと比較します。
     イベント ビューアのログおよびパフォーマンス モニタのログを、前述の 3 つの表を使用して分析すると、枯渇しているカーネル メモリ空間はすぐに明らかになります。
3. カーネル メモリ空間の枯渇を引き起こしている原因を特定します。

   1. ページ プールまたは非ページ プール内のどのタグが、メモリの枯渇状態を引き起こしているのかを判別します。
      オペレーティング システムは、タグを使用してページ プールおよび非ページ プールのカーネル メモリの割り当てを追跡します。Windows Server 2003 は既定でこれを行います。Microsoft Windows 2000 Server では、グローバル フラグ エディタ ユーティリティ (gflags.exe) を使用して、プールのタグ付けを有効にします。メモリのトラブルシューティングに関連するフラグの詳細については、マイクロソフト サポート技術情報の文書番号 177415「Memory Pool Monitor (Poolmon.exe) を使用してカーネル モードのメモリ リークのトラブルシューティングを行う方法」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=177415) およびサポート技術情報の文書番号 298102「サードパーティ製のドライバによって使用されているプール タグの検索方法」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=298102) を参照してください。
      Memory Pool Monitor (poolmon.exe) または MemSnap メモリ プロファイリング ツール (/p スイッチを使用した memsnap.exe) を実行して、タグをファイルにダンプし、どのタグが大部分のページ プールまたは非ページ プール メモリを消費しているかを特定します。スケジュールされた間隔で MemSnap メモリ プロファイリング ツールを実行すると、カーネル メモリ リークを特定するのに役立ち、割り当てが時間の経過と共にどのように変化したかを示す情報が得られます。MemSnap メモリ プロファイリング ツールの詳細については、Memsnap の概要についてのページ (https://go.microsoft.com/fwlink/?LinkId=50167) を参照してください (このサイトは英語の場合があります)。

      MemSnap メモリ スナップショットの例

      タグの種類	割り当て	空き	差異	バイト数	割り当てごと
      AGP 非ページ	1	0	1	344	344
      AGP ページ	7	5	2	384	192
      AcdN 非ページ	2	0	2	1,072	536
      AcpA 非ページ	39	36	3	192	64
      AcpA ページ	1	0	1	504	504
      AcpB ページ	42	38	4	576	144
      AcpD 非ページ	315	170	45	15,080	335
      AcpF 非ページ	493	485	8	320	40

      上の表に示される例で、「バイト数」列を使用して、最も多くのメモリを消費しているタグを特定します。この例では、それは AcpD 非ページです。潜在的なメモリ リークを追跡するために、「割り当て」と「空き」の列を使用します。「割り当て」と「空き」の値が大きく異なる場合、潜在的なメモリ リークがあることを示します。

   2. ページ プールまたは非ページ プール タグを、アプリケーションまたはドライバと照合します。以下のリソースを使用して、問題のタグを呼び出しアプリケーションまたはドライバと照合します。
      Windows 向けの Microsoft デバッグ ツールをダウンロードします (https://go.microsoft.com/fwlink/?LinkId=50168)。インストールすると、%program files%\Debugging Tools for Windows\triage ディレクトリに "pooltag.txt" が置かれ、それにより Microsoft アプリケーションまたはドライバと関連するタグ間のマッピングが可能になります。たとえば、次のようなことを行います。
      Ntf?- ntfs.sys - NTFS 固有の割り当てタグ
      Ntf0 - ntfs.sys - 一般的なプール割り当て
      Ntf9 - ntfs.sys - 大きな一時バッファ
      タグの詳細については、マイクロソフト サポート技術情報の文書番号 298102「サードパーティ製のドライバによって使用されているプール タグの検索方法」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=298102) を参照してください。
      タグ割り当てリークに対する修正措置を実行します。
      リークの発生しているタグが、Microsoft 製のアプリケーションまたはドライバである場合 (前述の pooltag.txt ファイルに示されるように)、Microsoft 製品サポート サービスにお問い合わせください。
      リークの発生しているタグが、サード パーティ製のアプリケーションまたはドライバである場合、サード パーティの製造元のサポート サービスにお問い合わせください。
      適切な場合は、リークが修正されるまで、システムの安定性を保つために問題のアプリケーションまたはドライバを無効にするか、アンインストールしてください。

   3. メモリ割り当て率が高いが、リークの発生している証拠はないタグに対する修正措置を実行します。
      ページ プールまたは非ページ プールがかなりの量のカーネル メモリ (非ページ プールの場合はおよそ 10 MB/タグ、ページ プールの場合は 40 MB/タグ) を消費しているが、タグのリークは発生していないケースがあります。通常、このようなケースは、Exchange メールボックス サーバーを 4,000 以上のメールボックスにスケールアップするか、10,000 を超えるメッセージを持つメッセージ配信キューを処理する場合に発生します。
      以下に、タグの割り当てに基づくメモリの高使用率の特定のケースを示します。
      TOKE ページ プール タグ このタグは、サーバーに対して開かれるすべてのユーザー セッションのセキュリティ情報をキャッシュするために、Windows によって使用されます。たとえば、Microsoft Office Outlook などの電子メール クライアントによって生成されたすべてのユーザー セッションに対して、トークン (TOKE ページ プール タグを使用して割り当てられたメモリで) が作成されます。クライアントによっては、各電子メール クライアントに対して複数のセッションが開かれる場合があり、各クライアントに対してサーバー上に複数のトークンがキャッシュされることになります。各トークンのページ プール メモリの使用量は、通常ユーザーが属するセキュリティ グループの数に基づいています。ユーザーが属するセキュリティ グループの数が多いほど、より多くのページ プール メモリがそのユーザーのセッションに関連付けられたトークンによって消費されます。
      次の表の MemSnap 出力では、平均トークン サイズは約 3 KB です。

      MemSnap メモリ スナップショットの例

      タグの種類	割り当て	空き	差異	バイト数	割り当てごと
      ページングされた TOKE	4,856,027	4,855,591	436	12,093,848	2,967

      TOKE タグがページ プール メモリを消費する主な要因となっている場合のページ プール メモリの枯渇を修正するために、次の手順を実行します。
      トークンあたりのページ プール メモリの使用量 (割り当てごとの TOKE) が 8 KB を超える場合 :
      •   組織内のセキュリティ グループの数を減らします。
      •   セキュリティ グループを統合し、深い入れ子を排除します。
      •   トークンあたりのページ プール メモリの使用量 (割り当てごとの TOKE) が 8 KB 未満である場合 :
      •   ページ プールの枯渇がメールボックス サーバーで発生した場合は、サーバー上のメールボックスの数を減らすか、またはメールボックス サーバーからパブリック フォルダの役割を除去します。
      •   ページ プールの枯渇がパブリック フォルダ サーバーで発生した場合は、既定のパブリック ストアとしてパブリック フォルダ サーバーを使用するメールボックス ストアの数を減らします。これにより、パブリック フォルダ サーバー上のクライアントの数 (およびその結果としてユーザー セッションの数) が減少します。
      •   Outlook の予定表の共有が広範囲に使用されている場合、すべてのクライアントが Outlook 2003 以降を実行していることを確認します。予定表の共有は、追加のユーザー セッションを作成することにより、サーバー上のトークンの負荷を増やします。Outlook 2003 は、以前のバージョンに比べて、このタスクをより効率的に少ないセッションで実行します。
      MMST ページ プール タグ Windows キャッシュ マネージャは、ファイルのキャッシュにこのタグを使用します。Windows キャッシュ マネージャは、プールが使い果たされると、自動的にファイル キャッシュを減らしてページ プール メモリを開放します。Exchange ベスト プラクティス アナライザ ツールが SMTP 構成について警告またはエラーを報告しなければ、修正措置は必要ありません。既定以外の、または正しくない SMTP 設定は、Windows キャッシュ マネージャに余計な負荷をかけ、そのためにより多くのページ プール メモリが消費されることがあります。
      ページ プールが枯渇する症状や MMST ページ プール タグに関連するイベントが発生した場合は、Microsoft 製品サポート サービスに連絡してください。
      AUXL および FLST 非ページ プール タグ これらのタグは exifs.sys で使用されます。exifs.sys は、Exchange ストア ドライバがメッセージング データベースとの間で、アイテムの読み取りと書き込みに使用するカーネルモード ドライバです。
      これらのタグのいずれかが非ページ プール メモリを消費する主な要因となっている場合は、Microsoft 製品サポート サービスに連絡してください。
      IpSA 非ページ プール タグ IPSec.sys は、IPSec (IP セキュリティ) の主要なデバイス ドライバで、この Windows タグを使用して、ページ プール メモリに格納されているセキュリティ アソシエーションにアクセスします。Exchange サーバーで IPSec.sys を使用すると、非ページ プールのオーバーヘッドが増加します。非ページ プールが枯渇する問題で、このタグが非ページ プール メモリを消費する主な要因となっている場合は、次の修正措置を検討してください。
      非ページ プールの枯渇がメールボックス サーバーで発生した場合は、サーバー上のメールボックスの数を減らすか、またはメールボックス サーバーからパブリック フォルダの役割を除去します。
      非ページ プールの枯渇がパブリック フォルダ サーバーで発生した場合は、そのパブリック フォルダ サーバーを既定のパブリック ストアとして設定しているメールボックス ストアの数を減らします。これにより、パブリック フォルダ サーバー上のクライアントの数 (およびその結果としてユーザー セッションの数) が減少します。

   4. PTE 枯渇の原因を特定します。これは、ページまたは非ページ プールの枯渇の原因の特定ほど単純ではありません。PTE の消費を追跡する、MemSnap のようなツールはありません。PTE の枯渇シナリオを解決するために取ることができるのは、一般的な修正措置のみです。
      PTE リークの場合 リークによる PTE の枯渇は、パフォーマンス モニタを使用して特定できます (空きシステム PTE と関連付けられた、上記のカウンタを使用します)。PTE リークは、数日間にわたって Performance Monitor Memory\Free System PTE が連続して不足していることから明らかになります。PTE リークの状態の診断については、Microsoft 製品サポート サービスにお問い合わせください。
      PTE 枯渇の場合 (リークの生じている証拠がない場合) PTE 枯渇は PTE リークが生じていない場合に発生する可能性があります。通常このようなケースには、4,000 以上のメールボックスへの Exchange メールボックス サーバーのスケールアップや、サード パーティ製のドライバによる PTE の枯渇が関係しています。PTE 枯渇を解消するには、次の修正措置を実行します。
      •   すべての不要なサード パーティ製のドライバを削除します。
      •   /BASEVIDEO または汎用ビデオ ドライバを使用して、システム ページ テーブル エントリを解放します。ビデオ ボードは、カーネル空間のバッファをマップするためにシステム ページ テーブル エントリを使用します。これは、Microsoft Exchange によるシステム ページ テーブル エントリの使用と競合します。
      •   使用可能な PTE を追加するために、boot.ini の /USERVA 設定を削減します。これを行うには、マイクロソフト サポート技術情報の文書番号 823440「Windows Server 2003 ベースのシステム上の Exchange Server 2003 での /3GB スイッチの使用」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=823440) の手順に従ってください。
      •   PTE の枯渇がメールボックス サーバーで発生した場合は、サーバー上のメールボックスの数を減らすか、またはメールボックス サーバーからパブリック フォルダの役割を除去します。
      •   PTE の枯渇がパブリック フォルダ サーバーで発生した場合は、既定のパブリック ストアとしてパブリック フォルダ サーバーを設定するメールボックス ストアの数を減らします。この操作により、パブリック フォルダ サーバー上のクライアントの数 (およびその結果としてユーザー セッションの数) が減少します。

Exchange ストアの仮想メモリを調べる

サーバーの各 Store.exe プロセスが処理できるメモリ (ストア仮想メモリと呼ばれる) の量には制限があります。より多くのユーザーとより頻繁な使用に対応するためにサーバーを拡張すると、サーバーの仮想メモリが不足する場合があります。サーバーに既に 4 GB の RAM がある場合、サーバーのメモリをそれ以上拡張することはできません。物理メモリを追加しても、仮想メモリが不足していることを示すエラーは解決できません。

サーバーで仮想メモリが不足すると、メモリ不足の状態によって Store.exe プロセスはページ ファイルの使用を強制され、Store.exe プロセスが高速でページングを開始するため、サーバーの全体的なパフォーマンスが低下します。

次の表に示すパフォーマンス カウンタを使用して、ストアの仮想メモリの現在の状態を判別できます。

Exchange ストアの仮想メモリのパフォーマンス カウンタ

Store.exe プロセスはまた、exchmem と呼ばれる独自のヒープ割り当てメカニズムと構造を使用します。Store.exe プロセスは、起動時にいくつかの exchmem ヒープを作成し、既存のヒープがすべて使用されるか、断片化されて、割り当てを続行するために十分な連続メモリが見つからない状態になるまで、ヒープの数を増やしません。

メモリ使用の問題または内部断片化 (exchmem ヒープの内部の断片化で、それ自体がストアの仮想メモリ空間内に存在する) がある場合は、Store.exe プロセスは新しい exchmem ヒープを作成します。

通常、Store.exe プロセスが繰り返し追加のヒープを作成する必要があると、全体的なストア仮想メモリが断片化されるか、使い果たされてしまいます。次の表に示すカウンタを追跡することで、exchmem ヒープが、ヒープの断片化を引き起こすことによって問題またはパフォーマンス低下の原因となっているかどうかを確認することができます。

exchmem ヒープのパフォーマンス カウンタ

Exchange ストアの仮想メモリを向上させる

次の一覧では、Exchange ストアの仮想メモリのパフォーマンスを向上する方法を示しています。

• ストレージ グループを統合する
  各ストレージ グループに対し、Store.exe プロセスは構造を割り当て、メモリを消費しなければなりません。可能な限り、SLA を満たす最小数のストレージ グループを使用してください。これは、Exchange 2003 よりも Exchange 2000 においてより重要です。Exchange 2003 では、追加のストレージ グループあたりの仮想メモリ使用量の増加を減らすため、大幅な変更が行われました。その結果、Exchange Server 2003 において、ストレージ グループまたはデータベース構成が仮想メモリの断片化の根本的な原因となる可能性はほとんどありません。Exchange 2003 でストレージ グループを構成する方法の詳細については、マイクロソフト サポート技術情報の文書番号 890699「ストレージの構成方法が Exchange でサーバー 2003 をグループ化します。」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=890699) を参照してください。
• サーバーの役割をオフロードする
  サーバーが複数の役割を実行しているためにメモリ使用率が高くなっている場合 (パブリック フォルダやメールボックス サーバーなど)、役割を専用サーバーにオフロードすることをお勧めします。
• マイクロソフト サポート技術情報の文書番号 815372 を読む
  仮想メモリの使用量を最適化する方法の詳細については、マイクロソフト サポート技術情報の文書番号 815372「Exchange Server 2003 でメモリ使用量を最適化する方法」(https://go.microsoft.com/fwlink/?linkid=3052&kbid=815372) を参照してください。