排除記憶體繫結問題

上次修改主題的時間： 2006-07-25

Exchange Server 原本就是一套十分耗用記憶體的工具，最多可以用到 3 GB 的實體記憶體。在生產伺服器上，常見到 Store.exe 處理程序使用 1.5 GB 的虛擬記憶體，因為這個處理程序需維持大量的記憶體快取。

除了 Exchange 內各個處理程序的記憶體使用率，Exchange 的 ExIFS 核心驅動程式也會用到核心記憶體。雖然不明顯，但大量使用核心記憶體確實造成嚴重的效能退化和不穩定性。

查看使用者空間記憶體

隨著伺服器使用記憶體，可用的記憶體愈來愈少，作業系統開始縮減處理程序的工作集，也更積極地利用分頁檔。使用分頁檔會影響整體效能，因為磁碟作業所需的時間比記憶體作業更久。

此外，當進出磁碟的分頁活動過於頻繁時，終究免不了遇上磁碟瓶頸，效能將大打折扣。在這種情況下，真正的問題在於記憶體，磁碟瓶頸只是徵兆。

請使用下表列出的計數器來判斷使用者空間記憶體目前的狀態。

使用者空間記憶體的效能計數器

改進使用者空間記憶體

下列清單說明如何改進使用者空間記憶體的效能：

• 移除多餘的軟體
  若要釋放資源給 Exchange，請從伺服器中移除任何執行遠端監視的協力廠商軟體工具，或任何不重要的服務類型。請利用 [效能] 嵌入式管理單元來瞭解每一個應用程式消耗多少記憶體。
• 在離峰時間執行維護工作
  在尖峰時間執行維護工具 (例如 eseutil) 或工作 (例如信箱管理) 會佔用 Exchange 所需的記憶體。最好在離峰時間或低用量期間 (例如週末) 執行這些工具和工作。

查看核心記憶體使用量

為了確保順利部署 Exchange Server，另外也必須監視 Windows 核心記憶體 (或稱為核心)，它是由核心作業系統所用的幾個記憶體結構組成。本節說明如何監視和疑難排解會影響 Exchange 伺服器效能和可靠性的核心記憶體結構。

在執行 Exchange 的伺服器上，應該監視三個重要的核心記憶體結構：

• 分頁集區 分頁集區是共用系統記憶體的部分，可分頁至磁碟分頁檔。分頁集區是在系統初始化時建立，供核心模式元件用來配置系統記憶體。
• 未分頁集區 未分頁集區由系統虛擬位址組成，這些位址保證一直都存在實體記憶體內，不必經過分頁輸入/輸出 (I/O) 就可讓任何位址空間存取。就像分頁集區一樣，未分頁集區也是在系統初始化時建立，供核心模式元件用來配置系統記憶體。
• 系統 PTE 分頁檔虛擬記憶體位址經由分頁表來對應到實體記憶體位址。Microsoft Exchange Server 2003 使用一群系統「分頁表項目」(PTE) 來對應系統分頁，例如 I/O 空間、核心堆疊及記憶體描述元清單。

Boot.ini 檔案設定會影響核心記憶體空間的大小

Microsoft Windows Server™ 2003 boot.ini 檔案中的設定會影響 Exchange 伺服器上的核心記憶體空間的大小上限。例如，如果 boot.ini 檔案中使用 /3GB 參數，3 GB 的虛擬位址空間就會分配給使用者模式處理程序，只有 1 GB 的虛擬位址空間會分配給作業系統。

如需使用 /3GB 參數的相關資訊，請參閱下列 Microsoft 知識庫文章：

• 823440＜在 Windows Server 2003 型系統上的 Exchange Server 2003 中使用 /3GB 參數＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=823440) (英文)
• 316739＜如何搭配 /3GB 參數使用 /userva 參數，將使用者模式空間調整成介於 2 GB 與 3 GB 之間的值＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=316739)

下表顯示在執行 Exchange 的伺服器上，每一個核心記憶體空間的約略大小上限如何隨著 boot.ini 設定而改變。在這個範例中，Exchange Server 2003 是在執行 Windows Server 2003 且配備 4 GB RAM 的多處理器伺服器上執行。

Boot.ini 設定和核心記憶體空間大小上限

下表顯示在配備 4 GB RAM 和執行 Windows Server 2003 的多處理器伺服器上執行之 Exchange Server 的效能監視器警示設定。在「警示」等級上，伺服器很穩定，但應該調查記憶體配置是否有遺漏。在「嚴重」等級上，伺服器處於變成不穩定的危險情況，尤其在負載高峰期。

使用不同 Boot.ini 檔設定的效能監視器警示設定

* 在未安裝 Service Pack 1 的 Windows Server 2003 上，效能監視器的 "Memory\Free System Page Table Entries" 計數器不正確。如需這個計數器的詳細資訊，請參閱 Microsoft 知識庫文章 894067＜效能工具並未正確顯示 Windows Server 2003 中可用的 Free System Page Table Entries＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=894067) (英文)。

在執行 Exchange 的伺服器上核心記憶體耗盡的徵兆

在執行 Exchange 的伺服器上核心記憶體耗盡的徵兆，包括回應遲鈍，甚至當場故障。

在執行 Exchange 的伺服器上核心記憶體耗盡的徵兆

在執行 Exchange 的伺服器上對核心記憶體進行疑難排解

如果上述表格「使用不同 Boot.ini 檔設定的效能監視器警示設定」中顯示的效能監視器核心記憶體計數器在建議的值之外，且/或如果發生「在執行 Exchange 的伺服器上核心記憶體耗盡的症狀」表格中描述的徵兆，請採取下列疑難排解方法來判斷核心記憶體耗盡的原因。

1. 請執行 Microsoft Exchange Server Best Practices Analyzer 工具來判斷 Exchange 伺服器是否設定正確。
   有各種組態設定會影響 Exchange Server 核心記憶體空間 (例如，先前討論的 /3GB 和 /Userva boot.ini 設定、SystemPages 登錄機碼等)。在調查核心記憶體耗盡徵兆前，確定伺服器的核心記憶體已正確設定是非常重要的。請執行 Microsoft Exchange Server Best Practices Analyzer 工具，並仔細檢閱輸出，確定伺服器組態正確。如需此工具的相關資訊，請參閱 Microsoft 下載中心的 Exchange Server Best Practices Analyzer 工具 (英文)。
2. 判斷哪一個核心記憶體空間正逐漸耗盡。
   • 分析事件 分析事件檢視器記錄，找出集區和未分頁集區配置失敗事件 (事件識別碼 2019 和 2020)。
   • 分析效能 使用效能監視器來建立分頁集區、未分頁集區及可用系統 PTE 的記錄，以 24 小時為期限，每隔 60 秒採樣一次。比較效能監視器記錄結果和先前在「使用不同 Boot.ini 檔設定的效能監視器警示設定」表格中顯示的警示和嚴重觸發程序。
     使用先前顯示的三個表格來分析事件檢視器和效能監視器記錄時，應該可以明顯看出逐漸耗盡的核心記憶體空間。
3. 判斷什麼原因導致核心記憶體空間耗盡。

   1. 判斷集區及/或未分頁集區記憶體中哪些標籤造成記憶體耗盡狀況。
      作業系統使用標籤來追蹤集區和未分頁集區核心記憶體配置。Windows Server 2003 依預設採取這種作法；Microsoft Windows 2000 Server 使用 Global Flags Editor 公用程式 (gflags.exe) 來啟用集區標籤。如需記憶體疑難排解相關標幟的相關資訊，請參閱 Microsoft 知識庫文章 177415＜如何使用記憶體集區監視器 (Poolmon.exe) 來疑難排解核心模式記憶體遺漏＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=177415) (英文) 和知識庫文章 298102 - ＜如何尋找協力廠商驅動程式所使用的集區標籤＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=298102) (英文)。
      執行記憶體集區監視器 (poolmon.exe) 或 MemSnap 記憶體剖析工具 (memsnap.exe 加上 /p 參數)，將標籤傾印至檔案，然後判斷哪個標籤消耗最多集區或未分頁集區記憶體。以預定的間隔時間來執行 MemSnap 記憶體剖析工具，有助於隔離核心記憶體遺漏，可看出這段期間的配置有何改變。如需 MemSnap 記憶體剖析工具的相關資訊，請參閱＜Memsnap 概觀＞ (https://go.microsoft.com/fwlink/?LinkId=50167) (英文)。

      範例 MemSnap 記憶體快照集

      Tag Type	Allocs	Frees	Diff	Bytes	Per Alloc
      AGP Nonp	1	0	1	344	344
      AGP Paged	7	5	2	384	192
      AcdN Nonp	2	0	2	1,072	536
      AcpA Nonp	39	36	3	192	64
      AcpA Paged	1	0	1	504	504
      AcpB Paged	42	38	4	576	144
      AcpD Nonp	315	170	45	15,080	335
      AcpF Nonp	493	485	8	320	40

      在上表顯示的範例中，請使用 "Bytes" 欄位來隔離出哪個標籤消耗最多記憶體。在這個範例中是 AcpD Nonp。請利用 "Allocs" 和 "Frees" 欄位來追蹤潛在的記憶體遺漏。如果 Allocs 和 Frees 值相差太大，就表示有潛在的記憶體遺漏。

   2. 比對集區或未分頁集區標籤與應用程式或驅動程式。請利用下列資源來比對有疑問的標籤與發出呼叫的應用程式或驅動程式：
      下載和安裝 Microsoft 偵錯工具 (https://go.microsoft.com/fwlink/?LinkId=50168)。安裝作業會將 "pooltag.txt" 放在 %program files%\Debugging Tools for Windows\triage 目錄中，這個檔案提供 Microsoft 應用程式或驅動程式與相關標籤之間的對應。例如：
      Ntf?- ntfs.sys - NTFS 專用配置標籤
      Ntf0 - ntfs.sys - 一般集區配置
      Ntf9 - ntfs.sys - 大型暫存緩衝區
      如需標籤的相關資訊，請參閱 Microsoft 知識庫文章 298102＜如何尋找協力廠商驅動程式所使用的集區標籤＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=298102) (英文)。
      採取更正動作來解決標籤配置遺漏問題：
      如果遺漏的標籤是 Microsoft 所開發的應用程式或驅動程式 (如前述的 pooltag.txt 檔所示)，請連絡 Microsoft 產品支援服務。
      如果遺漏的標籤是協力廠商所開發的應用程式或驅動程式，請連絡協力廠商的支援服務。
      在修正遺漏問題之前，可能的話，請停用或解除安裝有問題的應用程式及/或驅動程式，以維持系統的穩定性。

   3. 採取更正動作來解決記憶體配置頻繁但看不出遺漏問題的標籤。
      集區或未分頁集區標籤中有時會消耗大量的核心記憶體 (未分頁集區每個標籤約 10MB，分頁集區每個標籤約 40MB)，但標籤並無遺漏。這種情形通常出現在 Exchange 信箱伺服器增加到 4,000 個以上的信箱時，或在處理超過 10,000 封郵件的郵件傳遞佇列時。
      下列是標籤配置方面出現高記憶體使用量的特殊情況：
      TOKE 分頁集區標籤 Windows 使用這個標籤來快取對伺服器開啟的每一個使用者工作階段的安全性資訊。例如，電子郵件用戶端 (例如 Microsoft Office Outlook) 產生的每一個使用者工作階段會建立一個 Token (以 TOKE 分頁集區標籤來配置記憶體)。視用戶端而定，每一個電子郵件用戶端可能開啟多個工作階段，導致伺服器為每一個用戶端快取多個 Token。每一個 Token 的分頁集區記憶體使用量，通常取決於使用者所隸屬的安全性群組數目。一個使用者所隸屬的安全性群組愈多，該使用者工作階段相關的 Token 所消耗的分頁集區記憶體就愈多。
      在下表的 MemSnap 輸出中，平均 Token 大小約為 3 KB。

      範例 MemSnap 記憶體快照集

      Tag Type	Allocs	Frees	Diff	Bytes	Per Alloc
      Toke Paged	4,856,027	4,855,591	436	12,093,848	2,967

      請採取下列步驟來更正分頁集區記憶體耗盡的問題，其中，TOKE 標籤是分頁集區記憶體的主要消耗者：
      如果每個 Token 的分頁集區記憶體使用量 (TOKE per Alloc) 大於 8 KB：
      •   減少組織中的安全性群組數目。
      •   合併安全性群組，避免深層巢狀。
      如果每個 Token 的分頁集區記憶體使用量 (TOKE Per Alloc) 小於 8 KB：
      •   如果信箱伺服器上發生分頁集區耗盡，請減少伺服器上的信箱數目，以及/或從信箱伺服器中移除公用資料夾角色。
      •   如果公用資料夾伺服器上發生分頁集區耗盡，請減少以公用資料夾伺服器做為預設公用儲存區的信箱儲存區數目。這樣可減少公用資料夾伺服器上的用戶端數目 (因而減少使用者工作階段數目)。
      •   如果經常使用 Outlook 的行事曆共用，請確定所有用戶端都執行 Outlook 2003 或更新的版本。行事曆共用會建立更多使用者工作階段，在伺服器上造成更多 Token 負載。Outlook 2003 在執行這項工作上，比舊版本更有效率 (較少的工作階段)。
      MMST 分頁集區標籤 Windows 快取管理員會將這個標籤用於檔案快取。當集區逐漸耗盡時，Windows 快取管理員會自動減少檔案快取來釋放分頁集區記憶體。如果 Exchange Best Practices Analyzer 工具未回報任何關於 SMTP 組態的警告或錯誤，則不需要任何更正動作。非預設或不正確的 SMTP 設定可能會加重 Windows 快取管理員的負載，導致消耗更多分頁集區記憶體。
      如果出現分頁集區耗盡的徵兆及/或 MMST 分頁集區標籤相關的事件，請連絡 Microsoft 產品支援服務。
      AUXL 和 FLST 未分頁集區標籤 這些標籤是由 exifs.sys 使用，此檔案是核心模式驅動程式，供 Exchange 儲存區驅動程式用來讀取和寫入郵件資料庫的項目。
      如果其中任一標籤是未分頁集區記憶體的主要消耗者，請連絡 Microsoft 產品支援服務。
      IpSA 未分頁集區標籤 IPSec.sys (主要的 IPSec (IP 安全性) 裝置驅動程式) 會使用這個 Windows 標籤來存取分頁集區記憶體中儲存的安全關聯。在 Exchange 伺服器上使用 IPSec.sys 會增加未分頁集區負荷量。在未分頁集區耗盡情況下，如果這個標籤是未分頁集區記憶體的主要消耗者，請考慮採取下列更正動作：
      如果信箱伺服器發生未分頁集區耗盡，請減少伺服器上的信箱數目，以及/或從信箱伺服器中移除公用資料夾角色。
      如果公用資料夾伺服器上發生未分頁集區耗盡，請減少將公用資料夾伺服器設為預設公用儲存區的信箱儲存區數目。這樣可減少公用資料夾伺服器上的用戶端數目 (因而減少使用者工作階段數目)。

   4. 隔離 PTE 耗盡的原因，但不像隔離分頁或未分頁集區耗盡的原因那麼簡單。沒有像 MemSnap 的工具可追蹤 PTE 消耗。只能採取一般的更正動作來解決 PTE 耗盡狀況。
      PTE 遺漏案例 效能監視器可隔離由於遺漏所造成的 PTE 耗盡 (使用上述與可用系統 PTE 相關的計數器)。PTE 遺漏現象會在幾天內連續消耗效能監視器 Memory\Free System PTE。請連絡 Microsoft 產品支援服務，尋求協助來診斷 PTE 遺漏狀況。
      無遺漏現象的 PTE 耗盡案例 無 PTE 遺漏的情況下也可能發生 PTE 耗盡。這種情況通常是因為 Exchange 信箱伺服器增加到 4,000 個以上的信箱，或與協力廠商驅動程式消耗 PTE 有關。請採取下列更正動作來解決 PTE 耗盡問題：
      •   移除任何多餘的協力廠商驅動程式。
      •   使用 /BASEVIDEO 或一般視訊驅動程式來釋放系統分頁表項目。視訊介面卡會使用系統分頁表項目來對應核心空間中的緩衝區。這種用法會與 Microsoft Exchange 對系統分頁表項目的需求產生競爭。
      •   降低 boot.ini 中的 /USERVA 設定，增加更多可用的 PTE。作法請參閱 Microsoft 知識庫文章 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 2000 的重要性更勝於 Exchange 2003。Exchange 2003 已做重大的修改，來降低每增加一個儲存群組所增加的虛擬記憶體使用量。因此，在 Exchange Server 2003 中，儲存群組或資料庫組態不太可能是虛擬記憶體分散狀況的原因。如需在 Exchange 2003 中設定儲存群組的相關資訊，請參閱 Microsoft 知識庫文章 890699＜如何在 Exchange Server 2003 中設定儲存群組＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=890699) (英文)。
• 轉移伺服器角色
  如果記憶體使用率因為伺服器扮演多個角色而增加 (例如當做公用資料夾和信箱伺服器)，最好將角色轉移給其他專用的伺服器。
• 閱讀 Microsoft 知識庫文章 815372
  如需如何最佳化虛擬記憶體使用量的相關資訊，請參閱 Microsoft 知識庫文章 815372＜如何將 Exchange Server 2003 中的記憶體使用量最佳化＞(https://go.microsoft.com/fwlink/?linkid=3052&kbid=815372)。