Windows Live
Facebook
Twitter
Linkedin
Digg it
Yahoo
Delicious
StumbleUpon
Yammer
Reddit
Technorati
FriendFeed
Email文章編號: 918643 - 上次校閱: 2009年5月27日 - 版次: 9.0 如何疑難排解記憶體遺漏或記憶體不足例外狀況在 BizTalk Server 處理序中
在此頁中結論記憶體遺漏 (Memory Leak) 是一個常見的問題。您可能需要嘗試在 Microsoft BizTalk Server 中尋找特定的記憶體遺漏或記憶體不足 (OOM) 例外狀況原因的幾個步驟。本文將告訴您正在評估記憶體用量和可能的記憶體相關問題時要考慮的重要事項。這些考量包括下列：
簡介本文將告訴您，如何疑難排解記憶體遺漏或記憶體不足例外狀況在 BizTalk Server 處理序中的 Microsoft BizTalk Server。 其他相關資訊當 Microsoft Windows 工作管理員] 中的記憶體使用量會消耗超過 50%的實體 RAM，BizTalk Server 處理序可能會遭遇記憶體遺漏。記憶體使用量會增加，直到處理程序執行的系統記憶體不足，或直到處理序停止運作時，記憶體遺漏可能會造成記憶體不足例外狀況。 這個問題時警告訊息，類似下列的訊息會記錄事件記錄檔： 鍵入事件： 警告 事件類型： 警告 重要考量事項實體的 RAM 及記憶體使用量因為它可能會讓處理序 (Process) 使用大約一半實體的 RAM，請使用記憶體使用量做為指引預期的行為。比方說如果 BizTalk Server 具有 4 GB 的 RAM，並 BizTalk Server 處理序使用約 500 MB 的 RAM，可能遺漏。如果 BizTalk Server 處理序會使用大約 1 GB 的 RAM，可能有記憶體流失或高記憶體的情況。記憶體耗用量的原因可能是長時間執行的預存程序或協調流程。請確定您知道 BizTalk 主應用程式通常使用，以判斷是否發生記憶體遺漏或高記憶體條件多少記憶體。大型郵件當 BizTalk Server 處理大郵件時，系統似乎有記憶體流失。不過，郵件可能正在使用大量的記憶體。如需有關大型郵件的詳細資訊，請造訪下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站]：http://blogs.msdn.com/biztalk_core_engine/archive/2005/02/28/381700.aspx
(http://blogs.msdn.com/biztalk_core_engine/archive/2005/02/28/381700.aspx)
而且，請考慮是否 BizTalk Server 正在處理較大的郵件可能會預期高的記憶體使用量。若要升級您的硬體，以符合您的環境中 BizTalk Server 效能需求。重新產生記憶體遺漏所花費可以立即發生記憶體遺漏 (Memory Leak)，或他們可能會累積經過一段時間。這兩種案例是公用的。使用 / 3GB 參數，在 32 位元電腦上通常，處理程序可以存取 2 GB 的虛擬位址空間。/ 3GB 參數是需要更多的定址記憶體的系統上的選項。這個選項會改進處理訊息的記憶體使用量。不過，/ 3GB 參數允許只有 1 GB 的核心模式下作業的定址記憶體。此外，這個參數可能會增加風險的集區記憶體不足。如 3 GB 的相關資訊切換，請造訪下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站]： http://msdn.microsoft.com/en-us/library/ms791558.aspx
(http://msdn.microsoft.com/en-us/library/ms791558.aspx)
當 / 3GB 參數在 32 位元版本的 Windows 上啟用、 處理序可以存取 3 GB 的虛擬位址空間，如果處理程序是大型位址注意。 處理程序是大型位址時可執行檔已經在映像標頭中設定了 IMAGE_FILE_LARGE_ADDRESS_AWARE 旗標。因為 BizTalk 程序是大型位址注意，BizTalk 會獲益 / 3GB 參數。如果執行在 64 位元版本的 Windows (AMD64) 上的 32 位元 BizTalk 主控件執行個體 BizTalk 程序好處，從 4 GB 記憶體位址空間因為 BizTalk 是大型位址注意。因此，移動到 64 位元伺服器應用程式最高的記憶體，可能是最佳的解決方案。 在 64 位元版本的 Windows (AMD64) 在 64 位元 BizTalk 程序沒有 8 TB 定址記憶體。 您也應該考慮虛擬位元組和處理序所使用的私用位元組。BizTalk 主控件執行個體 (也就是.NET Framework 應用程式) 可能會收到一個記憶體不足的錯誤之前虛擬位元組值到達 2 GB。就會發生這個問題即使可定址的最大記憶體由處理序在 32 位元版本的 Windows 上 (而不需 / / 3GB 切換) 為 2 GB。如就為什麼會發生這個問題的說明請造訪下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站： http://msdn.microsoft.com/en-us/library/ms972959.aspx
(http://msdn.microsoft.com/en-us/library/ms972959.aspx)
http://blogs.msdn.com/tess/archive/2005/11/25/496898.aspx
(http://blogs.msdn.com/tess/archive/2005/11/25/496898.aspx)
/ 3GB 參數也會增加 BizTalk 程序從 800 MB 到 1800 MB 的最大的私用位元組。與.NET Framework 應用程式效能的相關資訊之 / / 3GB 參數啟用，請造訪下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站： http://msdn2.microsoft.com/en-us/library/ms998583.aspx
(http://msdn2.microsoft.com/en-us/library/ms998583.aspx)
下表摘要了這項資訊，並包括虛擬位元組和私用位元組實際的限制。摺疊此表格
http://msdn.microsoft.com/en-us/library/aa366778.aspx
(http://msdn.microsoft.com/en-us/library/aa366778.aspx)
下表列出不同版本的 BizTalk Server PAE 與 / 3GB 支援能力。摺疊此表格
網際網路資訊服務 (IIS) 處理序內執行的 BizTalk 元件也可能獲得好處何時 / 3GB 參數啟用。 / 3GB 執行 Windows SharePoint 服務 2.0 或更新版本或 SharePoint 入口網站 Server 2003 SP2 或更新版本的電腦上不支援參數。如需詳細資訊，請按一下下列的文件編號，檢視 「 Microsoft 知識庫 」 中的文件： 933560?
(http://support.microsoft.com/kb/933560/
)
不支援 Windows Server 2003 / 3GB 參數，以 Windows SharePoint 服務 2.0 或更新版本中或在 SharePoint 入口網站伺服器 2003年服務套件 2 或更新版本中 自訂元件的使用如果您使用如管線或服務元件的自訂元件，您必須知道這些元件執行什麼動作。 您也必須知道對記憶體使用量，將這些元件的潛在之影響。當元件轉換文件時，就會發生常見的記憶體問題。轉換操作是需要大量記憶體的作業。當轉換文件 BizTalk Server 會將訊息資料流傳遞給 Microsoft.NET Framework XslTransform 類別 BizTalk 處理序中。使用大量字串操作時，就會發生另一個常見的問題。使用大量字串操作會消耗大量記憶體。如需有關改善效能的方法的詳細資訊，請造訪下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站]： http://msdn2.microsoft.com/en-us/library/ms998547
(http://msdn2.microsoft.com/en-us/library/ms998547)
.NET Framework 版本Microsoft.NET Framework 2.0 和.NET Framework 1.1 有不同的記憶體行為。因此，您可能會看到它們之間的不同結果。 如果您使用.NET Framework 1.1，確認.NET Framework 1.1 Service Pack 1 (SP1) 安裝。SP1 解決許多記憶體問題。 如需詳細資訊，請按一下下列的文件編號，檢視 「 Microsoft 知識庫 」 中的文件：867460?
(http://support.microsoft.com/kb/867460/
)
.NET Framework 1.1 Service Pack 1 中所修正的 Bug 清單 處理器數量通用語言執行階段 (CLR) 具有下列的記憶體回收行程 (GC)：
如果執行 BizTalk Server 的電腦是單一處理器系統，.NET Framework 會使用工作站版本的執行引擎。這是預設行為。工作站記憶體回收行程配置演算法不被設計或最大輸送量的縮放比例。這個記憶體回收行程會使用並行的記憶體回收行程的方法。這些方法是專為有複雜的使用者介面的應用程式而設計。這類應用程式可能需要更積極的回收。 重要這個區段、 方法或任務包含告訴您如何修改登錄的步驟。然而，如果您不當修改登錄，可能會發生嚴重的問題。因此，執行這些步驟時請務必小心。為加強保護，修改登錄之前，請務必將它備份起來。以後您就可以在發生問題時還原登錄。如需有關如何備份和還原登錄的詳細資訊，請按一下下面的文件編號，檢視「Microsoft 知識庫」中的文件： 322756?
(http://support.microsoft.com/kb/322756/
)
如何備份和還原在 Windows 登錄 有時候，可能適合在多處理器系統上執行的執行引擎工作站版本。若要切換到的執行引擎工作站版本，您可以使用下列登錄機碼：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{7F09E353-4EFC-440B-249D-9D4ED58795FB}\ 數值名稱： 類別 實值型別: 字串 值的資料： wks http://msdn2.microsoft.com/en-us/library/ms973838
(http://msdn2.microsoft.com/en-us/library/ms973838)
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx (http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx) 常見的原因和解決方案處理序的記憶體用量和實體記憶體使用量節流閾值處理序記憶體使用量 和 實體記憶體使用量 節流臨界值可在 BizTalk Server 2006 和更新版本中變更。
http://msdn.microsoft.com/en-us/library/aa559628.aspx
(http://msdn.microsoft.com/en-us/library/aa559628.aspx)
凍結節流閾值64 位元的主控件上執行的協調流程時，預設記憶體凍結臨界值可能會造成過多的凍結。如需有關這個問題的詳細資訊，請參閱下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站上的 凍結預設內容 主題：http://msdn.microsoft.com/en-us/library/aa560586.aspx
(http://msdn.microsoft.com/en-us/library/aa560586.aspx)
附註 64 位元主機支援 BizTalk Server 2006 和更新版本中。32 位元的主控件執行個體中的對等硬體上, 觀察到的凍結時名義上利用節流閾值的預設記憶體凍結執行相同的協調流程。 因為 64 位元架構提供擴充的記憶體位址空間 (16 TB 代替 4 GB)，64 位元的主控件執行個體配置比 32 位元的主控件執行個體大幅更多的記憶體。 這可能會造成預設記憶體節流閾值，以超過。 如果要解決這個問題，變更 BTSNTSvc64.exe.config 檔案 [VirtualMemoryThrottlingCriteria 和 PrivateMemoryThrottlingCriteria 值。用於 Process\Virtual 位元組和 Process\Private 位元組效能監視器計數器判斷協調流程執行個體配置的記憶體最大數量。
如果 \Process\Private 位元組效能監視器計數器值 435689400 位元組 (415 MB) 請 OptimalUsage 值設為 PrivateMemoryThrottlingCriteria 457 MB (435689400 * 1.10 = 479258340 位元組)。MaximalUsage 值設為 PrivateMemoryThrottlingCriteria 594 MB (479258340 * 1.30 = 623035842)。 為使本範例會將下列值指定以減少節流 BTSNTSvc64.exe.config 檔案中。 摺疊此表格
<xlangs>
<Configuration>
<Dehydration>
<VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
<PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
</Dehydration>
</Configuration>
</xlangs>附註過度凍結在 BizTalkMsgBoxDb 資料庫正在執行 SQL Server 2008 上時，可能會導致明顯而導致效能降低。 BizTalk Server 2004如果您正在使用 BizTalk Server 2004，可能會遇到一些記憶體相關問題。如果要解決這些問題，套用 BizTalk Server 2004 Service Pack 2 (SP2)] 及 [最新的作業系統 Service Pack。HeapDeCommitFreeBlockThreshold根據預設，theHeapDeCommitFreeBlockThreshold 登錄機碼值是 0。0 表示堆集管理 decommits，就可以使用每一 4 千位元組 (KB)] 頁的值。decommit 作業可能會導致虛擬記憶體分散。HeapDeCommitFreeBlockThreshold 設定堆積管理員中的大小將視系統正在進行的工作種類而定。0x00040000 大小是建議的起始值。變更 HeapDeCommitFreeBlockThreshold 登錄機碼的值之前，請考慮下列資訊：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session
Manager 數值名稱： HeapDeCommitFreeBlockThreshold 實值型別： REG_DWORD 值的資料： 0x00040000 (這是建議的起始值)。 預設的值： 沒有顯示出來 315407?
(http://support.microsoft.com/kb/315407/
)
HeapDecommitFreeBlockThreshold 」 登錄機碼 轉換作業BizTalk Server 會在中傳送埠的接收埠執行相當大的郵件上的 XML 轉換作業，或在 [XLANG，XSL 轉換時載入記憶體中的整個訊息如果要解決這個問題，使用下列方法之一：
大部分的預設 BizTalk 運算質會實作成內嵌指令碼。這些項目可能會造成 System.Byte 收集在記憶體中的 [] 物件。減到最少記憶體耗用量，我們建議您將放到小的組件會使用這些運算質的地圖。然後，參考該組件。 若要判斷哪一個運算質使用內嵌指令碼使用下列的圖表，並哪一個運算質不使用內嵌指令碼。 是第二欄中 「] 」 表示此運算質實作為內嵌指令碼以及它會造成收集 System.Byte [] 物件在記憶體中。「 無 」 表示此運算質未實作做為內嵌指令碼，它不會造成 System.Byte 收集在記憶體中的 [] 物件。 摺疊此表格
http://msdn2.microsoft.com/en-us/library/aa560481.aspx
(http://msdn2.microsoft.com/en-us/library/aa560481.aspx)
大型的屬性值和大型的項目值BizTalk Server 在 XML 文件上執行接收管線] 或 [傳送管線時, 如果文件中包含一或多個下列的實體，將處理裝載在記憶體中：
自訂管線元件您正在使用整個資料流載入記憶體的自訂管線元件。所包含的 BizTalk Server 轉換，以外的所有元件都支援資料流。這些元件並不會使用期間資料流一樣多的記憶體。不過，自訂管線元件可能不支援資料流。重裝壓力之下串流處理傳送主機記憶體用完時它們操作重型壓力之下。 BizTalk Server 傳送管線和傳送配接器支援資料流。資料流處理中, 每個元件會載入至記憶體資料流的小片段。 因為每個訊息包含加上可以是大或小的訊息內容的其他資料結構這種行為會影響重型壓力之下的 BizTalk Server 行為。BizTalk Server 行為會受到影響，因為引擎載入預先設定的郵件數目。引擎載入的郵件數目根據出現在 [LowWaterMark 欄位及 Adm_serviceClass 資料表的 [HighWaterMark] 欄位的值。 Adm_serviceClass 資料表位於 BizTalk 管理資料庫。這些值會控制 BizTalk Server 處理，或在同一時間傳送的郵件的數目。 HighWaterMark 值是引擎處理在同一時間的訊息總數。預設值為 200 的訊息，每個 CPU。因此，8 個處理器伺服器上傳送主機會試著在同一時間處理 1,600 訊息 (200 * 8)。如果您假設每個訊息為 50 KB，郵件等號 80 MB (1、 600 * 50 = 80，000 KB)。 如果要解決這個問題，您可以變更 HighWaterMark 值和資料庫中的 LowWaterMark 值。您使用的值是根據訊息的大小而定。 記憶體不足狀況的常見原因的相關資訊，請參閱 「 記憶體等比在 BizTalk 傳訊 」 一節在下列 Microsoft 網站： http://blogs.msdn.com/biztalkperformance
(http://blogs.msdn.com/biztalkperformance)
BizTalk Server 2006 和更新版本，您可以變更預設主控件節流設定。如需有關如何變更預設主控件節流設定的詳細資訊，請造訪下列 Microsoft 開發 o 人 h 員 ? 工 u 具 ? 網路 (MSDN) 網站]：http://msdn2.microsoft.com/en-us/library/aa559628.aspx
(http://msdn2.microsoft.com/en-us/library/aa559628.aspx)
請試著簡化問題如果您已找出記憶體遺漏，請試著判斷原因，藉由移除自訂元件或簡化地圖。而且，嘗試重現問題，使用簡單的協調流程或簡單的解決方案。通常，您應該建立個別接收主機的接收配接器。您也應該建立傳送配接器的個別傳送主機。當您使用這種方式時，每個介面卡可以在不同的處理序中執行。因此，如果您的 BizTalk Server 處理序中發生記憶體不足狀況就會知道涉及哪些元件。疑難排解步驟若要記憶體不足狀況的疑難排解使用偵錯診斷 」 工具來監視記憶體配置經過一段時間。偵錯診斷工具可以建立並分析記憶體遺漏傾印 (.dmp) 檔案。當您疑難排解記憶體遺漏 (Memory Leak) 時，目標是高記憶體條件來擷取經過一段時間的記憶體成長會重現之前附加 Leaktrack.dll。Leaktrack.dll 會包含與 「 偵錯診斷 」 工具。
如何使用效能監視器記錄選取要記錄的資料選取資料記錄，請使用適合您作業系統的方法：
取得傾印檔案如果要取得傾印檔案，使用下列方法之一：
停止效能監視器記錄如果您擷取記憶體傾印和效能監視器資料，停止 [效能監視器記錄大約兩分鐘後建立記憶體傾印]。分析傾印檔案若要協助您判斷記憶體遺漏的原因，您可以使用偵錯診斷 」 工具來分析傾印檔案。要這麼做，請您執行下列步驟：
如果您使用 [自訂的 DLL，您可以新增自訂的.pdb 檔案進行分析的符號路徑。要這麼做，請您執行下列步驟：
http://support.microsoft.com/contactus/?ws=support
(http://support.microsoft.com/contactus/?ws=support)
請聯絡客戶支援服務之前先壓縮傾印檔案]、 [效能監視器記錄檔]、 [分析報告檔案] 及 [更新的事件記錄檔 (.evt 檔案)。您可能必須傳送到 BizTalk Server 這些檔案支援工程師。這篇文章中的資訊適用於:
 機器翻譯重要：本文是以 Microsoft 機器翻譯軟體翻譯而成，而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章，讓使用者可以依其使用語言使用知識庫中的所有文章。但是，機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤，就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。 按一下這裡查看此文章的英文版本：918643?
(http://support.microsoft.com/kb/918643/en-us/
)
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應，不負任何擔保責任。Microsoft及(或)其供應商謹此聲明，不負任何對與此資訊有關之擔保責任，包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。 | 其他資源 其他支援網站社群立即取得協助文章翻譯 |
回此頁最上方
