共用方式為

如何針對 BizTalk Server 程式中的記憶體流失或記憶體不足例外狀況進行疑難解答

  • 發行項

本文說明如何在 Microsoft BizTalk Server 的 BizTalk Server 程式中，針對記憶體流失或記憶體不足例外狀況進行疑難解答。

原始產品版本：BizTalk Server 2010 年 2009 年
原始 KB 編號： 918643

摘要

記憶體流失是常見的問題。 您可能必須嘗試幾個步驟來找出 Microsoft BizTalk Server 中記憶體流失或記憶體不足 (OOM) 例外狀況的特定原因。 本文討論評估記憶體使用量時要考慮的重要事項，以及可能的記憶體相關問題。 這些考慮包括下列事項：

  • 實體 RAM
  • 大型訊息處理
  • 使用 /3GB 參數
  • 使用自訂元件
  • 系統執行的 Microsoft .NET Framework 哪個版本
  • 處理器的數目

當 Microsoft Windows 任務管理員中的記憶體使用量耗用超過 50% 的實體 RAM 時，BizTalk Server 程式可能會發生記憶體流失。 當記憶體使用量增加，直到行程用完系統記憶體，或直到進程停止運作時，記憶體流失可能會導致記憶體不足的例外狀況。 針對此問題，請考慮下列事項：

實體 RAM 和記憶體使用量

因為進程使用大約一半的實體 RAM 可能是預期的行為，所以請使用記憶體使用量做為指導方針。 例如，如果 BizTalk Server 具有 4 GB (GB) RAM，且 BizTalk Server 進程使用約 500 MB (MB) RAM，則可能不會發生流失。 如果 BizTalk Server 進程使用大約 1 GB 的 RAM，可能會發生記憶體流失或記憶體偏高的情況。 記憶體耗用量可能是長時間執行的預存程式或協調流程所造成。 請確定您知道 BizTalk 主機通常會使用多少記憶體來判斷是否發生記憶體流失或高記憶體狀況。

大型訊息

當 BizTalk Server 處理大型訊息時，系統似乎發生記憶體流失。 不過，訊息可能會使用大量的記憶體。

此外，請考慮如果 BizTalk Server 處理大型訊息，可能會預期會有高記憶體使用量。 您可能想要升級硬體，以符合環境中 BizTalk Server 效能需求。

重現記憶體流失需要多久時間

記憶體流失可能會立即發生，或隨著時間累積。 這兩種情況很常見。

在32位電腦上使用 /3GB交換器

一般而言，進程可以存取 2 GB 的虛擬位址空間。 /3GB 參數是需要更多可尋址記憶體之系統的選項。 此選項可改善處理訊息的記憶體使用量。 不過， /3GB 參數 只允許 1 GB 的可尋址記憶體用於內核模式作業。 此外，此參數可能會增加集區內存用完的風險。

在 32 位版本的 Windows 上啟用 /3GB 交換 器時，如果進程有大型位址感知，進程可以存取 3 GB 的虛擬地址空間。 當可執行檔在影像標頭中設定 IMAGE_FILE_LARGE_ADDRESS_AWARE 旗標時，進程會感知大型位址。 因為 BizTalk 程式具有大型位址感知，所以 BizTalk 將受益於 /3GB 參數。

如果 32 位 BizTalk 主機實例是在 64 位版本的 Windows (AMD64) 上執行，BizTalk 程式會受益於 4 GB 的記憶體地址空間，因為 BizTalk 具有大型位址感知。 因此，將高記憶體應用程式移至64位伺服器可能是最佳的解決方案。

64 位版本 Windows 上的 64 位 BizTalk 進程 (AMD64) 有 8 TB 的可尋址記憶體。

您也應該考慮進程所使用的虛擬位元組和私用位元組。 BizTalk 主機實例 (這是 .NET Framework 應用程式，) 可能會在虛擬位元組值達到 2 GB 之前收到記憶體不足錯誤。 即使 32 位版本 Windows 上的進程可尋址的最大記憶體 (沒有 /3GB 參數 ，) 為 2 GB，仍可能發生這種情況。 如需這種情況發生原因的說明，請造訪下列 Microsoft Developer Network (MSDN) 網站：
ASP.NET 效能監視，以及警示系統管理員的時機

/3GB 參數也會將 BizTalk 進程的最大私用位元組從 800 MB 增加到 1800 MB。 如需啟用 /3GB 參數 .NET Framework 應用程式效能的詳細資訊，請流覽第 17 章：調整 .NET 應用程式效能。

下表摘要說明這項資訊，並包含虛擬位元組和私用位元組的實際限制。

程序 Windows 具有大型位址感知程式的可尋址記憶體 () 虛擬位元組的實際限制 私人位元組的實際限制
32 位元 32 位元 2 GB 1400 MB 800 MB
32 位元 具有 /3GB 的32位 3 GB 2400 MB 1800 MB
32 位元 64 位元 4 GB 3400 MB 2800 MB
64 位元 64 位元 8 TB 不適用 不適用

如需 32 位與 64 位 Windows 的可尋址記憶體的詳細資訊，請造訪 Windows 和 Windows Server 版本的記憶體限制。

下表列出不同版本 BizTalk Server 的PAE和3 GB支援能力。

產品 Pae 3 GB
BizTalk Server 2004 是 否
BizTalk Server 2006 是 是
BizTalk Server 2006 R2 是 是
BizTalk Server 2009 是 是

如果您必須啟用 /3GB 參數，以符合執行 BizTalk Server 之計算機的效能需求，您可以考慮將伺服器新增至 BizTalk 群組。 這可讓您相應放大記憶體密集型主機實例。

啟用 /3GB 參數 時，在 Internet Information Services (IIS) 行程內執行的 BizTalk 元件也可能受益。

執行 2.0 版或更新版本或 2003 SP2 或更新 SharePoint Portal Server 版本 Windows SharePoint Services 電腦不支援 /3GB 交換器。 Windows SharePoint Services 2.0 或更新版本或 SharePoint Portal Server 2003 Service Pack 2 或更新版本不支援 Windows Server 2003 /3GB 參數。

使用自訂元件

如果您使用自定義元件，例如管線或服務元件，您必須知道這些元件的用途。 您也應該知道這些元件對記憶體使用量的潛在影響。 當元件正在轉換檔時，會發生常見的記憶體問題。 轉換作業是需要大量記憶體的作業。 轉換檔時，BizTalk Server 會將訊息串流傳遞至 BizTalk 進程內的 Microsoft .NET Framework XslTransform 類別。

有密集的字串操作時，會發生另一個常見的問題。 密集的字串操作可能會耗用許多記憶體。 如需如何改善效能的詳細資訊，請造訪 改善 Managed 程式代碼效能。

.NET Framework的版本

Microsoft .NET Framework 2.0 和 .NET Framework 1.1 有不同的記憶體行為。 因此，您可能會看到它們之間的不同結果。 如果您使用 .NET Framework，請確認已安裝最新的 .NET Framework Service Pack 1。 此 Service Pack 可解決數個已知的記憶體問題。

處理器數目

Common Language Runtime (CLR) 具有下列垃圾收集行程 (GC) ：

  • 工作站 (Mscorwks.dll)
  • 伺服器 (Mscorsvr.dll)

如果執行 BizTalk Server 的電腦是多處理器系統，.NET Framework 會使用執行引擎的Server版本。 這是預設行為。 伺服器垃圾收集行程是針對最大輸送量所設計。 此外，伺服器垃圾收集行程會進行調整以提供高效能。 此垃圾收集行程會配置記憶體，然後稍後釋放記憶體，以在系統上提供高效能。 因此，與某些 .NET Framework元件一起執行 BizTalk Server 的計算機似乎有記憶體流失。 不過，在此案例中，高記憶體使用量是預期的行為。 如果計算機用完系統記憶體，或進程因為可尋址記憶體不足而停止運作，則可能會有記憶體流失狀況。

如果執行 BizTalk Server 的電腦是單一處理器系統，則 .NET Framework 會使用執行引擎的工作站版本。 這是預設行為。 工作站垃圾收集行程配置演算法並非專為調整規模或達到最大輸送量而設計。 此垃圾收集行程會使用並行垃圾收集行程方法。 這些方法是針對具有複雜使用者介面的應用程式所設計。 這類應用程式可能需要更積極地進行垃圾收集。

重要事項

這個章節、方法或工作包含修改登錄的步驟。 但是，如果您不正確地修改登錄，可能會發生嚴重問題。 因此，請務必仔細遵循這些步驟。 為了有多一層保護，請先備份登錄再進行修改。 如此一來，您就可以在發生問題時還原登錄。 如需進一步了解如何備份及還原登錄的相關資訊，請參閱如何在 Windows 中備份及還原登錄。

有時候，在多處理器系統上執行執行引擎的工作站版本可能很適合。 您可以使用下列登入機碼切換至執行引擎的工作站版本。

BizTalk 2006 和更新版本

Create 下列內容CRL Hosting具有對應值的字串登入機碼：

  • 金鑰：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • 值名稱：Flavor
  • 值數據：wks

BizTalk 2004

Create 下列內容CRL Host具有對應值的字串登入機碼：

  • 金鑰：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • 值名稱：Flavor
  • 值數據：wks

如需詳細資訊，請造訪 .NET Framework 中 Run-Time 技術的效能考慮。

以下是常見原因和解決方法：

進程和物理記憶體使用量節流閾值

在 BizTalk Server 2006 和更新版本中，可以變更處理記憶體使用量和物理記憶體使用量節流閾值。

  • 根據預設， [處理記憶體使用量 ] 節流閾值會設定為 25。 如果超過此值，且 BizTalk 進程記憶體使用量超過 300 MB，可能會發生節流狀況。 在 32 位伺服器上，您可以將 Process 記憶體使用量值增加到 50。 在 64 位伺服器上，您可以將此值增加到 100。 這可讓 BizTalk 進程在節流發生之前，進一步耗用更多記憶體。

  • 物理記憶體使用量節流閾值的預設值為 0。 此臨界值會測量系統記憶體總計。 因此，如果設定了 0 以外的值，則非 BizTalk 進程使用高記憶體時，可能會發生節流狀況。

凍結節流閾值

在64位主機上執行協調流程時，預設記憶體凍結閾值可能會導致太多凍結。 如需此問題的詳細資訊，請參閱 解除凍結默認屬性。

注意事項

BizTalk Server 2006 和更新版本支援 64 位主機。

在 32 位主機實例中的對等硬體上，當使用預設記憶體解除凍結節流閾值執行相同的協調流程時，觀察到凍結是次要的。

因為 64 位架構提供擴充的記憶體位址空間 (16 TB，而不是 4 GB) ，所以 64 位主機實例會配置超過 32 位主機實例的記憶體。 這可能會導致超過預設記憶體節流閾值。

若要解決此行為，請變更 BTSNTSvc64.exe.config 檔案中的 VirtualMemoryThrottlingCriteria 和 PrivateMemoryThrottlingCriteria 值。 使用 \Process\Virtual Bytes 和 \Process\Private Bytes 效能監視器 計數器來判斷協調流程實例所配置的最大記憶體數量。

  • 根據下列項目，設定這兩個屬性的 OptimalUsage 值：

    • VirtualMemoryThrottlingCriteria： \Process\Virtual Bytes value + 10%
    • PrivateMemoryThrottlingCriteria： \Process\Private Bytes value + 10%

  • 將兩個屬性的 MaximalUsage 設定為 OptimalUsage 值 + 30%

例如，如果協調流程實例的 \Process\Virtual Byte 效能監視器 計數器值為 5,784,787,695 位元組， (5,517 MB) ， 將 VirtualMemoryThrottlingCriteria 的 OptimalUsage 值設定為 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 位元組) 。

將 VirtualMemoryThrottlingCriteria 的 MaximalUsage 值設定為 7,889 MB (6,363,266,464.5 * 1.30 = 8,272,246,403.85 位元組) 。

如果 \Process\Private Bytes 效能監視器 計數器值435689400位元組 (415 MB) ，請將 PrivateMemoryThrottlingCriteria 的 OptimalUsage 值設定為 457 MB (435689400 * 1.10 = 479258340 字節) 。

將 PrivateMemoryThrottlingCriteria 的 MaximalUsage 值設定為 594 MB (479258340 * 1.30 = 623035842) 。

在此範例中，會在 BTSNTSvc64.exe.config 檔中指定下列值，以減少節流。

效能監視器 計數器 配置的記憶體 OptimalUsage MaximalUsage
\Process\Virtual Bytes 5,784,787,695 位元組 (5517 MB) 6069 7889
\Process\Private Bytes 435,689,400 個字節 (415 MB) 457 594

這些值接著會在 BTSNTSvc64.exe.config 檔案中表示，如下所示：

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

若要判斷哪個主機實例正在執行協調流程，您可以比對 \BizTalk： Messaging\ID Process 和 \Process\ID Process 效能監視器 計數器中的標識符進程。 然後，檢查對應 \Process\Virtual Bytes 和 \Process\Private Bytes 效能監視器 計數器所顯示的平均值。

注意事項

用戶應該注意的資訊，即使略過，當資料庫在 2008 年 SQL Server 執行時BizTalkMsgBoxDb，高凍結可能會導致效能大幅降低。

BizTalk Server Service Pack 和累積更新

BizTalk Server Service Pack 和累積更新包含最新的修正程式。 其中包括會影響已知 System.OutOfMemoryException 問題的問題。

HeapDeCommitFreeBlockThreshold

根據預設，登錄 HeapDeCommitFreeBlockThreshold 機碼值為0。 值為 0 表示堆積管理員會取消認可每 4 KB (KB) 可用的頁面。 取消認可作業可能會導致虛擬記憶體分散。 堆積管理員中的設定大小 HeapDeCommitFreeBlockThreshold 將取決於系統正在執行的工作類型。 0x00040000的大小是建議的起始值。

變更登錄機碼的 HeapDeCommitFreeBlockThreshold 值之前，請先考慮下列資訊：

  • 這項變更僅適用於記憶體片段問題。
  • 這項變更是全系統的。 因此，大部分進程都會在啟動時使用更多記憶體。
  • 請只考慮對 BizTalk Server 作為其主要任務的系統進行這項變更。

若要協助減少虛擬記憶體片段，您可以變更 下HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager列登錄機碼的HeapDeCommitFreeBlockThreshold值，以增加堆積管理員中設定的大小：

  • 數值名稱：HeapDeCommitFreeBlockThreshold
  • 實值類型：REG_DWORD
  • 值數據：0x00040000 (这是建议的起始值。)
  • 默認值：不存在

轉換作業

當 BizTalk Server 在接收埠、傳送埠或 中的XLANG相當大型訊息上執行 XML 轉換作業時，XSL 轉換會將整個訊息載入記憶體中。

若要解決此問題，請使用下列其中一個方法：

  • 減少同時 BizTalk Server 處理的訊息數目。
  • 減少正在轉換的 XML 訊息大小。

System.Policy.Security.Evidence對象經常用於轉換，而且會耗用許多記憶體。 當對應包含使用內嵌 C# (或其他任何內嵌語言) 的腳本 functoid 時，會在記憶體中建立元件。 物件 System.Policy.Security.Evidence 會使用實際呼叫元件的物件。 這種情況會建立在 BizTalk 服務重新啟動之前不會刪除的 Root 物件。

大部分的預設 BizTalk functoids 都會實作為內嵌腳本。 這些專案可能會導致 System.Byte[] 物件在記憶體中收集。 若要將記憶體耗用量降至最低，建議您將任何使用這些的對 functoids 應放入小型元件中。 然後，參考該元件。 使用下列圖表來判斷哪一個 functoids 使用內嵌腳本，以及哪些 functoids 不使用內嵌腳本。

在第二個數據行中， [是 ] 表示這 functoid 會實作為內嵌腳本，而且會導致 System.Byte[] 物件在記憶體中收集。 否 表示這 functoid 不會實作為內嵌腳本，而且不會造成 System.Byte[] 對象在記憶體中收集。

運算質 內嵌腳本？
所有字串運算質 是
所有數學運算質 是
IsNil 以外的所有邏輯運算質 是
邏輯IsNil運算質 否
所有日期/時間運算質 是
所有轉換運算質 是
所有科學運算質 是
所有累計運算質 是
所有資料庫運算質 否
進階運算質 內嵌腳本？
迴圈運算質 否
Value-Mapping 壓平合併運算質 否
判斷提示運算質 否
數據表擷取器運算質 否
數據表迴圈運算質 否
使用內嵌 C 編寫運算質的腳本# 是
使用內嵌 JScript.NET 編寫運算質的腳本 是
使用內嵌 Visual Basic .NET 編寫運算質的腳本 是
使用內嵌 XSLT 編寫運算質的腳本 否
使用內嵌 XSLT 呼叫範本編寫運算質的腳本 否
呼叫外部元件的腳本運算質 否
Nil 值運算質 否
值對應運算質 否
大量複製運算質 否
反覆項目運算質 否
索引運算質 否
記錄計數運算質 否

BizTalk Server 2006 和更新版本可大幅改善大型文件的記憶體管理。 若要這樣做，BizTalk Server 實作可設定的訊息大小臨界值，以便在轉換作業期間將檔載入記憶體。 默認訊息大小閾值為 1 MB。 如需 TransformThreshold 設定的詳細資訊，請造訪 BizTalk Server 如何處理大型訊息。

大型屬性值和大型元素值

當 BizTalk Server 在 XML 檔上執行接收管線或傳送管線時，如果檔包含下列一或多個實體，則會在記憶體中處理承載：

  • 大型屬性值
  • 大型元素值
  • 大型屬性或項目標籤

若要解決此問題，請限制這些實體的大小。 如果無法使用此方法，請確定您的 BizTalk HOST 實例不會同時處理多個檔，例如這些檔。

自定義管線元件

您使用的自訂管線元件會將整個資料流載入記憶體中。 BizTalk Server 隨附的所有元件，除了轉換之外，都支援串流處理。 這些元件在串流期間不會使用太多記憶體。 不過，自定義管線元件可能不支援串流處理。

在壓力過重的情況下串流

當主機在壓力過重的情況下運作時，傳送主機記憶體不足。 BizTalk Server 傳送管線並傳送配接器支援串流。 在串流中，每個元件都會將數據流的一小部分載入記憶體中。 因為每個訊息都包含其他數據結構，以及可能顯著或小的訊息內容，所以此行為會影響 BizTalk Server 在繁重壓力下的行為。

BizTalk Server 的行為會受到影響，因為引擎會載入預先設定的訊息數目。 引擎載入的訊息數目是以出現在 LowWaterMark 字段和數據表 HighWaterMark 字段中的 Adm_serviceClass 值為基礎。 此 Adm_serviceClass 數據表位於 BizTalk 管理資料庫中。 這些值會控制 BizTalk Server 處理或同時傳送的訊息數目。

HighWaterMark 值是引擎同時處理的訊息總數。 預設值是每個 CPU 200 則訊息。 因此，在 8 個處理器的伺服器上，傳送主機會嘗試同時處理 1,600 個訊息 (200 * 8) 。

如果您假設每個訊息為 50 KB，則訊息等於 80 MB (1,600 * 50=80,000 KB) 。

若要解決此問題，您可以變更 資料庫中的 HighWaterMark 值和 LowWaterMark 值。 您使用的值取決於訊息的大小。 針對 BizTalk Server 2006 和更新版本，您可以變更預設主機節流設定。

嘗試簡化問題

如果您已識別出記憶體流失，請嘗試移除自定義元件或簡化對應來判斷原因。 此外，請嘗試使用簡單的協調流程或簡單的解決方案來重現問題。 一般而言，您應該為接收配接器建立個別的接收主機。 您也應該為傳送配接器建立個別的傳送主機。 當您使用這個方法時，每個配接器都可以在個別的進程中執行。 因此，如果您的 BizTalk Server 程式遇到記憶體不足的情況，您將知道涉及哪些元件。

疑難排解步驟

若要針對記憶體不足狀況進行疑難解答，請使用偵錯診斷工具來監視一段時間的記憶體配置。 偵錯診斷工具可以建立及分析記憶體流失傾印檔案 (.dmp) 。 當您針對記憶體流失進行疑難解答時，目標是在高記憶體狀況重現之前附加 Leaktrack.dll ，以擷取一段時間的記憶體成長。 Leaktrack.dll 隨附於偵錯診斷工具。

  1. 安裝偵錯診斷工具。

    下列檔案可供從 Microsoft 下載中心下載：
    立即下載偵錯診斷工具套件

    如需如何下載 Microsoft 支援檔案的詳細資訊，請參閱如何從 線上服務 取得 Microsoft 支援檔案。

    Microsoft 已掃描此檔案是否有病毒。 Microsoft 使用了最新的病毒偵測軟體，該軟體可在檔案張貼的日期取得。 檔案會儲存在安全性增強的伺服器上，以協助防止未經授權的檔案變更。

  2. 使用 效能監視器 收集系統效能的相關數據。 此數據可能會提供有關您 BizTalk Server 環境效率的重要指標。 目標是擷取一段時間的進程效能。 因此，請在發生記憶體流失之前啟用 效能監視器 記錄。

如何使用 效能監視器 記錄

下列各節說明如何使用性能監視器記錄。

選取要記錄的數據

若要選取要記錄的數據，請使用適合您操作系統的方法：

  • 適用於 Windows Server 2008 和 Windows Server 2008 R2

    1. 在 [系統管理工具] 中，開啟 [可靠性] 並 效能監視器。

    2. 以滑鼠右鍵按兩下 [效能監視器]，按兩下 [新增]，然後按兩下 [資料收集器集合器集合]。

    3. 在 [ 名稱] 方 塊中，輸入描述性名稱，然後按 [ 下一步]。

    4. 記下 根 目錄，然後按 [ 下一步]。

    5. 按兩下 [立即啟動此資料收集器集合器]，然後按兩下[ 完成]。

    6. 依 序展開 [數據收集器集合器集合]、[ 使用者定義 ]，然後選取您的檔案。

    7. 以滑鼠右鍵按兩下 [系統監視器記錄]，然後按下 [ 屬性]。

    8. 按兩下 [性能計數器] 索引標籤上的[新增]。選取下列物件，然後在選取每個物件之後按下 [新增]：

      • .Net CLR 例外狀況
      • .Net CLR 記憶體
      • BizTalk：傳訊
      • BizTalk：TDDS
      • 記憶體
      • 程序
      • 處理器
      • XLANG/s 協調流程

      如果 SQL Server 為本機，也請新增下列物件：

      • SQLServer：資料庫
      • SQLServer：一般統計數據
      • SQLServer：記憶體管理員

    9. 按一下確定。

    10. 將 [ 範例間隔值] 方塊變更為 5 秒。

      注意事項

      [範例間隔] 值和開始監視的時間是主體性的。 這些值取決於何時重現記憶體流失。 因為記錄檔可能很大，所以請指定一個間隔，讓您可以取得您必須擁有的資訊，而不會讓伺服器無法承受。

    11. 按一下確定。

若要停止收集數據，請按兩下 [動作] 功能表上的 [停止]。

  • 適用於 Windows Server 2003 或 Windows XP

    1. 展開 [ 效能記錄和警示]。

    2. 以滑鼠右鍵按兩下 [計數器記錄]，然後按下 [ 新增記錄設定]。 [ 新增記錄檔設定 ] 對話框隨即出現。

    3. 在 [ 名稱] 方 塊中，輸入描述性名稱，然後按兩下 [ 確定]。

    4. 記下記錄檔位置。 (您也可以按兩下 [ 記錄檔] 索引標籤， 然後按下 [設定] 變更記錄檔位置。)

    5. 按兩下 [新增計數器]。

    6. 選 取 [所有計數器 ] 和 [ 所有實例]。

    7. 在 [ 效能物件 ] 清單中，選取下列物件。 選取每個物件之後，按兩下 [ 新增 ]。

      • .Net CLR 例外狀況
      • .Net CLR 記憶體
      • BizTalk：傳訊
      • BizTalk：TDDS
      • 記憶體
      • 程序
      • 處理器
      • XLANG/s 協調流程

      如果 SQL Server 為本機，也請新增下列物件：

      • SQLServer：資料庫
      • SQLServer：一般統計數據
      • SQLServer：記憶體管理員

    8. 按一下 [關閉]。

    9. 將 [數據取樣間隔 ] 中的值變更為 5 秒。

      注意事項

      數據取樣間隔值和開始監視的時間是主體性的。 這些值取決於何時重現記憶體流失。 因為記錄檔可能很大，所以請指定一個間隔，讓您可以取得您必須擁有的資訊，而不會讓伺服器無法承受。

    10. 按一下確定。 若要停止收集數據，請以滑鼠右鍵按下計數器記錄檔的名稱，然後按兩下 [ 停止]。

取得傾印檔案

若要取得傾印檔案，請使用下列其中一種方法：

方法 1：自動

使用DebugDiag建立記憶體和處理流失規則是擷取記憶體轉儲的建議方法。 記憶體和處理流失規則會自動附加 Leaktrack.dll。 這是用來追蹤記憶體配置。 若要建立記憶體和處理流失規則，請遵循下列步驟：

  1. 啟動偵錯診斷工具 1.1。

  2. 選 取 [記憶體] 和 [處理流失]，然後按 [ 下一步]。

  3. 選取 Btsntsvc.exe 程序，然後按 [ 下一步]。

  4. 在 [ 設定洩漏規則 ] 頁面上，遵循下列步驟：

    1. 按兩下即可選取 [ 啟動規則啟動時立即啟動記憶體追蹤 ] 複選框。 否則，您可以在 BTSNTSvc.exe 程式中插入 LeakTrack.dll 之前指定準備時間。

    2. 按兩下 列動作： 設定，然後執行下列動作：

      • 確認已選取 [自動建立當機規則 ]。 藉由選取此選項，如果 BTSNTSvc.exe 進程停止，就會自動建立記憶體轉儲。

      • 按兩下以選取 [ 虛擬位元組到達時產生使用者傾印 ] 複選框，並將預設值保留 為1024。

      • 按兩下以選取 和每個額外的 複選框，並將預設值保留為200。 藉由選取虛擬位元組觸達選項，當虛擬位元組使用1024 MB時，將會自動建立記憶體轉儲。 如果虛擬位元組增加 200 MB，則會自動建立另一個記憶體轉儲。

    3. 按一下 [儲存後關閉]。

    4. 按一下[下一步]。

    5. 在 [ 選取傾印位置和規則名稱] 頁面上，按 [ 下一步]。

      注意事項

      您也可以在此頁面的 [ 使用者傾印位置 ] 方塊中變更傾印檔案的路徑。

    6. 按兩下 [完成 ] 讓規則立即啟用。

      注意事項

      規則狀態現在是 [追蹤]。 每次建立記憶體轉儲時，[規則] 索引標籤上的 [使用者傾印計數] 數據行中的值就會增加。預設記憶體轉儲位置為 C:\Program Files\DebugDiag\Logs。

方法 2：手動

您也可以手動附加 Leaktrack.dll，並手動取得記憶體轉儲檔案。 這可讓您控制何時建立記憶體轉儲。 如果要執行這項操作，請依照下列步驟執行：

  1. 啟動偵錯診斷工具 1.1。
  2. 按兩下 [ 行程] 索引 標籤。
  3. 以滑鼠右鍵按兩下 Btsntsvc.exe 程式，然後按兩下 [監視流失]。
  4. 在 [ 偵錯診斷工具 ] 對話框中，按兩下 [ 是]，然後按兩下 [ 確定]。

Create 當機規則來監視相同的 Btsntsvc.exe 進程，以防進程在您建立記憶體轉儲之前停止：

  1. 啟動偵錯診斷工具 1.1。
  2. 選取 [損毀]，然後按 [ 下一步]。
  3. 選取特定進程，然後按 [ 下一步]。
  4. 選取相同的 Btsntsvc.exe 程序，然後按 [ 下一步]。
  5. 在 [ 進階設定 (選用) ] 頁面上，按 [ 下一步]。
  6. 在 [ 選取傾印位置和規則名稱 (選用) ] 對話框中，按 [ 下一步]。
  7. 選 取 [立即啟用規則]，然後按兩下 [ 完成]。

當進程達到 60% 到 80% 的 RAM 時，以滑鼠右鍵按兩下 Btsntsvc.exe 程式，然後按兩下 [Create 完整使用者傾印]。 如果 BizTalk 行程在您建立使用者傾印之前停止，當機規則應該會生效並建立記憶體轉儲。

停止 效能監視器記錄

如果您要擷取記憶體轉儲並 效能監視器 數據，請在建立記憶體轉儲約兩分鐘後停止記錄 效能監視器。

分析傾印檔案

若要協助判斷記憶體流失的原因，您可以使用偵錯診斷工具來分析傾印檔案。 如果要執行這項操作，請依照下列步驟執行：

  1. 按兩下 [ 進階分析] 索引 標籤。
  2. 按兩下 [新增數據檔]，然後找出.dmp檔案。
  3. 選取 [記憶體壓力分析 ] 腳本，然後按兩下 [ 開始分析]。

根據預設，分析完成時，會在資料夾中 C:\Program Files\DebugDiag\Reports 建立 (.mht 檔案) 的分析報表檔案。 報表檔案也會顯示在瀏覽器中。 報表檔案包含分析的結果。 此外，報表檔案可能包含如何解決記憶體流失的建議。

如果您使用自定義 DLL，您可以新增自訂 .pdb 檔案的符號路徑進行分析。 如果要執行這項操作，請依照下列步驟執行：

  1. 開啟 [偵錯診斷] 工具。
  2. 在 [ 工具] 功能表上，按兩下 [ 選項和設定]。
  3. 在 [符號 搜尋 偵錯路徑] 方塊中，輸入符號路徑。

如果您想要分析傾印檔案的協助，請連絡 Microsoft 客戶支持服務。 如需客戶支援服務電話號碼的完整清單，以及支援成本的相關信息，請造訪 連絡支持人員。

在您連絡客戶支持服務之前，請先壓縮傾印檔案、效能監視器 記錄檔、分析報表檔案，以及更新的事件記錄 (.evt 檔案) 。 您可能必須將這些檔案傳送給 BizTalk Server 支持工程師。