使用適用于 BizTalk Server 的 PAL) 工具效能分析，產生具有效能計數器 (的報表和圖表
PAL (效能分析記錄) 工具會在效能監視器計數器記錄中讀取 (任何已知格式) ，並使用複雜但已知的臨界值 (提供) 進行分析。 此工具會產生 HTML 報表，以圖形方式繪製重要效能計數器的圖表，並在超過閾值時擲回警示。 閾值最初是以 Microsoft 產品小組定義的閾值為基礎，包括BizTalk Server，以及 Microsoft 支援的成員。 此工具不是取代傳統的效能分析，而是將效能計數器記錄的分析自動化，足以協助您節省時間。 PAL 工具：
分析閾值的效能計數器記錄
對於大型 Perfmon 記錄很有説明
藉由分析臨界值來識別BizTalk Server和作業系統效能計數器瓶頸
可擴充以在任何效能計數器上進行分析
可用來協助撰寫您自己的計數器
PAL 可在 GitHub免費下載。 它需要 Microsoft Log Parser。 記錄剖析器是一種功能強大的多用途工具，可提供文字型資料的通用查詢存取，例如記錄檔、XML 檔案和 CSV 檔案，以及 Windows 作業系統上的金鑰資料來源，例如事件記錄檔、登錄、檔案系統和 Active Directory 目錄®服務。 您可能想要使用此工具來查詢大量的記錄資訊。 您可以 下載記錄剖析器工具。
以不同語言搭配效能計數器記錄使用 PAL
PAL 工具只會以英文分析效能計數器記錄。 若要搭配其他語言的效能計數器記錄使用 PAL 工具，您必須先將記錄翻譯成英文。 您可以使用 Perfmon 記錄翻譯工具 將原始效能計數器記錄檔轉譯為英文。
瞭解 Microsoft BizTalk Server 2010 的 PAL 工具報告
PAL 工具提供 Windows 作業系統、Microsoft SQL Server和BizTalk Server閾值的 Perfmon 記錄分析。 本節說明 PAL 工具中BizTalk Server臨界值報告中的大部分分析。
注意
本主題很長，因此 PAL 工具的完整資訊可以包含在一個地方，方便參考。
PAL 工具會報告下列分析和臨界值。
| 分析類型和名稱 | 分析描述 |
|---|---|
| 磁片：核心傾印的磁片可用空間 | 此分析會檢查以確定作業系統有足夠的可用磁碟空間，以將所有記憶體傾印到磁片。 如果磁碟空間不足，則作業系統將無法建立 memory.dmp，這是分析核心傾印根本原因所需的檔案。 |
| 磁片：邏輯/實體磁片介面分析 | 此分析會查看每個實體磁片的閒置時間。 磁片越閒置，使用的磁片就越少。 當邏輯磁片中使用一個磁片時，最好使用此計數器。 「% Idle Time」 會報告磁片閒置的取樣間隔期間的時間百分比。 參考： 縮小 Disk-Bound 問題 |
| 磁片：邏輯/實體磁片讀取/寫入延遲分析 | Windows 偵測磁片效能瓶頸的最可靠方式是測量其回應時間。 如果回應時間大於 .025 (25 毫秒) ，這是保守的閾值，則可能會影響使用者的明顯緩慢和效能問題可能會發生。 如需詳細資訊，請參閱本主題中的邏輯/實體磁片讀取/寫入延遲分析。 |
| 磁片：邏輯磁片傳輸/秒 | 「磁片傳輸/秒」是磁片上讀取和寫入作業的速率。 此分析的臨界值會檢查是否有任何邏輯磁片顯示回應時間不佳， (I/O 作業) 大於 25 毫秒的回應時間。 如果這是 true，則每秒的磁片傳輸應為或高於 80。 如果沒有，則必須調查磁片架構。 磁片 I/O 不佳最常見的原因是 SAN 上的 LUN 多載。 如需詳細資訊，請參閱本主題中的邏輯磁片傳輸/秒。 |
| 磁片：LogicalDisk % 可用空間 | 「% 可用空間」 是所選邏輯磁片磁碟機上可用空間總計的百分比。 在可用的磁片磁碟機空間小於 30% 之前，效能不應該受到影響。 使用 70% 的磁片磁碟機時，剩餘的可用空間會接近磁片磁碟機中央的磁片軸，這會以較低的效能等級運作。 缺少可用磁碟空間可能會導致嚴重的磁片效能。 |
| 磁片：處理 IO 資料作業/秒和處理 IO 其他作業/秒分析 | 這些計數器會計算進程所產生的所有 I/O 活動，以包含檔案、網路和裝置 I/O。 這些分析會檢查進程每秒執行 1,000 個以上的 I/O，並將其標示為警告。 這些分析最適合與其他分析相互關聯，例如磁片分析，以判斷哪些進程可能涉及 I/O 活動。 |
| 記憶體：可用的記憶體 | 此分析會檢查可用記憶體總計是否很低 – 10% 可用的警告，以及 5% 可用的嚴重性。 當偵測到每小時 10 MB 的減少趨勢時，也會發出警告，這可能表示可能即將發生的記憶體狀況。 低實體記憶體可能會導致特殊許可權模式 CPU 和系統延遲增加。 如需詳細資訊，請參閱本主題中的可用 MemoryAnalysis。 |
| 記憶體：釋放系統分頁表專案 | PTE () 的免費系統分頁表專案是系統目前未使用的分頁表專案數目。 此分析會檢查是否有少於 5,000 個可用 PTE 的 PTE，並檢查是否有少於 10,000 個可用 PTE 的 PTE，來判斷系統是否用盡。 缺少足夠的 PTE 可能會導致全系統停止回應。 另請注意，/3GB 參數會大幅降低可用 PTE 的數量。 如需詳細資訊，請參閱本主題中的免費系統頁面資料表專案分析。 |
| 記憶體：記憶體流失偵測 | 此分析會判斷任何進程是否耗用大量的系統記憶體，以及進程是否隨著時間而增加記憶體耗用量。 只要進程將記憶體傳回系統，耗用大量記憶體的進程就沒問題。 尋找圖表中的增加趨勢。 長時間增加的趨勢可能表示記憶體流失。 「私用位元組」是這個進程配置而無法與其他進程共用的記憶體目前大小，以位元組為單位。 此分析會檢查每小時 10 MB，以及每小時增加 5 MB 的趨勢。 使用此分析與 PAL 中的可用記憶體分析相互關聯。 如需詳細資訊，請參閱本主題中的記憶體流失偵測分析。 |
| 記憶體：處理流失偵測 | 此分析會檢查所有進程，以判斷每個控制碼已開啟的控制碼數目，以及判斷是否有可疑的控制碼流失。 具有大量控制碼和/或積極向上趨勢的進程可能表示控制碼流失，這通常會導致記憶體流失。 此進程目前開啟的控制碼總數等於這個進程中每個執行緒目前開啟的控制碼總和。 參考： 偵錯診斷工具 |
| Memory： Memory Pages Input/sec | 「Pages Input/sec」 是從磁片讀取頁面以解決硬式分頁錯誤的速率。 當處理程序參照的虛擬記憶體分頁不在其於實體記憶體中的工作集或其他位置，因而必須從磁碟進行擷取時，就會發生硬體分頁錯誤。 此分析會檢查每秒是否讀取超過 10 個頁面檔案。 |
| Memory： Memory Pages/sec | 此分析會檢查 「Pages/sec」 是否高 (高於 1,000) 。 如果很高，則系統可能藉由嘗試將記憶體分頁至磁片而用盡。 「Pages/sec」 是頁面讀取或寫入磁片以解決硬式分頁錯誤的速率。 此計數器是造成全系統延遲之錯誤類型的主要指標。 使用此分析與 PAL 中的可用記憶體分析和記憶體流失偵測分析相互關聯。 如果所有這些分析同時擲回警示，這可能表示系統記憶體不足，以及涉及的可疑進程，並遵循 PAL 中記憶體流失偵測分析中所述的分析步驟。 如需詳細資訊，請參閱本主題中的記憶體頁面/秒分析。 |
| 記憶體：記憶體系統快取駐留位元組 | 「系統快取駐留位元組」是檔案系統快取中可分頁作業系統程式碼的大小，以位元組為單位。 這個值只包含目前的實體分頁，而不包含任何非目前駐留的虛擬記憶體分頁。 這個值是「記憶體\\系統程式碼駐留位元組」的元件，代表目前在實體記憶體中的所有可分頁作業系統程式碼。 此計數器只會顯示最後的觀察值；它不是平均值。 此分析會檢查每小時增加 10 MB 的趨勢。 在負載下，伺服器可能會使用系統快取來快取 I/O 活動，例如磁片。 在與 PAL 中的處理 IO 資料作業/秒和處理 IO 其他作業/秒分析相互關聯時使用。 參考： 檔案快取效能和微調 |
| 記憶體：集區非分頁位元組 | 「集區非分頁位元組」是非分頁集區的大小，這是無法寫入磁片之物件的系統記憶體區域，但只要配置它們，就必須保留在實體記憶體中。 此分析會檢查系統是否接近最大集區非分頁式記憶體大小。 其作法是估計考慮 /3GB、實體記憶體大小和 32 位/64 位的集區大小，然後判斷該值是否高於估計集區大小的 60%。 如果系統接近大小上限，則系統可能會遇到整個系統停止回應。 boot.ini 檔案中的 /3GB 參數選項可大幅減少此記憶體集區的大小。 如需詳細資訊，請參閱本主題中的集區非分頁位元組分析。 |
| 記憶體：集區分頁位元組 | 此分析會檢查系統是否接近集區分頁記憶體大小上限。 其作法是估計考慮 /3GB、實體記憶體大小和 32 位/64 位的集區大小，然後判斷該值是否高於估計集區大小的 60%。 如果系統接近大小上限，則系統可能會遇到整個系統停止回應。 boot.ini 檔案中的 /3GB 參數選項可大幅減少此記憶體集區的大小。 如需詳細資訊，請參閱本主題中的集區分頁位元組分析。 |
| 記憶體：進程執行緒計數 | 此分析會檢查所有進程，以判斷進程是否有超過 500 個執行緒，以及執行緒數目是否每小時增加 50 個執行緒。 具有大量執行緒和/或積極向上趨勢的進程可能表示執行緒流失，這通常會導致記憶體流失或高內容切換。 高內容切換會導致高許可權模式 CPU。 |
| 記憶體：進程工作集 | 「工作集」是此程式工作集的目前大小，以位元組為單位。 工作集是進程執行緒最近接觸的記憶體頁面集。 如果電腦的可用記憶體超過臨界值，即使頁面不在使用中，頁面仍會保留在進程的工作集中。 當可用記憶體低於臨界值時，頁面會從工作集修剪。 如果需要，則會在離開主要記憶體之前，將其軟容錯回復至工作集。 此分析會檢查每個處理常式中增加 10 MB 或更多趨勢。 在 PAL 中使用與可用記憶體分析相互關聯。 參考： 尋找並消除瓶頸 |
| 網路：網路輸出佇列長度分析 | 此分析會檢查網路介面卡上正在等候的執行緒數目。 如果許多執行緒在網路介面卡上等候，系統可能會因為網路延遲或網路頻寬而使網路 I/O 飽和。 「輸出佇列長度」是封包) 中輸出封包佇列 (的長度。 如果這超過兩個，則表示延遲是否超過兩個，而且應該盡可能找出並消除瓶頸。 網路輸出佇列的一般原因包括大量小型網路要求和網路延遲。 |
| 網路：網路使用率分析 | 「Bytes Total/sec」 是透過每個網路介面卡傳送和接收位元組的速率，包括框架字元。 「Network Interface\Bytes Received/sec」 是 「Network Interface\Bytes Received/sec」 和 「Network Interface\Bytes Sent/sec」 的總和。 此計數器可協助您知道網路介面卡上的流量是否飽和，以及是否需要新增另一個網路介面卡。 您可以快速識別問題取決於您擁有的網路類型，以及您是否與其他應用程式共用頻寬。 此分析會將 「Bytes Total/sec」 轉換成位，並將它與網路介面卡的目前頻寬進行比較，以計算網路使用率。 接下來，它會檢查使用率高於 50%。 參考： 在 .NET Core 中使用 EventCounters 測量效能 |
| 分頁檔案：分頁檔案 % 使用量和 % 使用量尖峰 | 以百分比為單位使用的頁面檔案實例數量。 另請參閱「Process\\Page File Bytes」。 此分析會檢查使用量百分比是否大於 70%。 |
| 處理器：處理器使用率分析和進程使用過多的處理器 | 此計數器是處理器活動的主要指標，並顯示樣本間隔期間觀察到的忙碌時間平均百分比。 其計算方式是監視服務處於非使用中狀態的時間，並從 100% 減去該值。 此分析會檢查每個處理器上的使用率是否大於 60%。 如果是，請判斷它是否為高使用者模式 CPU 或高特殊許可權模式。 如果可疑高特殊許可權模式 CPU，請參閱 PAL 中的特殊許可權模式 CPU 分析。 如果懷疑使用者模式處理器瓶頸，請考慮使用進程分析工具來分析造成高 CPU 耗用量的函式。 |
| 處理器：處理器佇列長度 | 此分析會判斷平均處理器佇列長度是否超過處理器數目。 如果是的話，這可能表示處理器瓶頸。 在與特殊許可權模式 CPU 分析和 PAL 中的進程分析過度使用的處理器相互關聯中使用這項分析。 如需詳細資訊，請參閱本主題中的處理器佇列長度分析。 |
| 處理器：特殊許可權模式 CPU 分析 | 此計數器表示執行緒以特殊許可權模式執行的時間百分比。 當您的應用程式呼叫作業系統函式 (例如執行檔案或網路 I/O 或配置記憶體) 時，這些作業系統函式會以特殊許可權模式執行。 此分析會檢查特殊許可權模式 CPU 是否耗用超過總 CPU 的 30%。 如果是，則 CPU 耗用量可能是因為處理器以外的另一個瓶頸所造成，例如網路、記憶體或磁片 I/O。 使用 與處理器相互關聯： % 停機時間和處理器：PAL 中的高內容切換分析。 如需詳細資訊，請參閱本主題中的特殊許可權模式 CPU 分析。 |
| 處理器：停機時間 | 「% 停機時間」是處理器在取樣間隔期間花費接收和維護硬體中斷的時間。 此值是產生插斷的裝置 (如系統時鐘、滑鼠、磁碟驅動程式、資料通訊線路、網路介面卡及其他週邊裝置) 活動的間接指示器。 當這些裝置完成工作或有需求時，通常會對處理器發出插斷。 在插斷期間會暫停執行一般執行緒。 大多數的系統時鐘會每隔 10 毫秒中斷一次處理器，以建立中斷活動的背景。 此計數器大幅增加表示潛在的硬體問題。 此分析會檢查大於 30% 的「%停機時間」。 如果發生這種情況，請考慮針對與此警示相互關聯的硬體更新裝置驅動程式。 參考： 在 .NET Core 中使用 EventCounters 測量效能 |
| 處理器：高內容切換 | 當優先順序較高的執行緒優先佔用目前執行的較低優先順序執行緒，或高優先順序執行緒區塊時，就會發生內容切換。 當許多執行緒共用相同的優先順序層級時，可能會發生高階的內容切換。 這通常表示系統上的處理器競爭太多執行緒。 一般規則是，每個處理器每秒少於 5,000 個的內容切換速率並不值得擔心。 如果每個處理器的內容切換速率超過每秒 15,000，則有一個條件約束。 如需詳細資訊，請參閱本主題中的高內容切換分析。 |
| Microsof BizTalk Server：BizTalk 解除凍結協調流程 | 當許多長時間執行的商務程式同時執行時，可能會發生記憶體和效能問題。 協調流程引擎透過「凍結」和「解除凍結」協調流程執行個體來解決這些問題。 凍結是將協調流程狀態序列化到 SQL Server 資料庫中的程序。 解除凍結是此程式的反向：從資料庫還原序列化協調流程的最後一個執行狀態。 凍結是藉由減少必須一次在記憶體中產生的協調流程數目，來將系統資源的使用降至最低。 因此，清除會節省記憶體耗用量，但執行的成本相對昂貴。 此分析會檢查 10 或以上的解除凍結。 若是如此，BizTalk Server可能會記憶體不足， (虛擬或實體) 、大量協調流程正在等候訊息，或未正確設定凍結設定。 參考： 協調流程解除凍結和解除凍結 |
| Microsoft BizTalk Server：BizTalk High Database 會話 | 此計數器有兩個可能的值：一般 (0) 或超過 (1) 。 此分析會檢查值 1。 如果是，BizTalk 已超過允許的資料庫會話數目閾值。 此值是由 BizTalk 主機節流設定中的「每個 CPU 的資料庫連線」值所控制。 「每個 CPU 的資料庫連線」是每個 CPU) 在節流開始之前允許的並行資料庫會話數目上限 (。 您可以使用 [BizTalk: 訊息代理程式] 效能物件類別下的 [資料庫工作階段] 效能計數器，來監控作用中資料庫連線數目。 此參數只會影響輸出訊息節流。 如需詳細資訊，請參閱本主題中的 BizTalk 高資料庫會話分析。 |
| Microsoft BizTalk Server：BizTalk 高資料庫大小 | 如果發生資料庫閾值中訊息計數所列的任一條件，此計數器將會設定為 1。 根據預設，資料庫節流閾值中的主機訊息計數設定為 50,000，這會在下列情況下觸發節流條件： - 主機實例發佈至訂閱主機的工作、狀態和暫停佇列的訊息總數超過 50,000。 - 多工緩衝處理資料表或追蹤資料表中的訊息數目超過 500,000 則訊息。 如果發生這種情況，請考慮可減少資料庫中訊息數目的動作。 例如，請確定BizTalk Server中的SQL Server作業執行時沒有錯誤，並使用 BizTalk Server 管理主控台中的 [群組中樞] 頁面來判斷訊息建置是否由大量暫止的訊息所造成。 如需詳細資訊，請參閱本主題中的 BizTalk 高資料庫大小分析。 |
| Microsoft BizTalk Server：BizTalk High In-Process 訊息計數 | 此分析會檢查高 In-Process 訊息計數計數器，以判斷是否發生這種節流。 如果是，請考慮調整 [每個 CPU 的進程內訊息] 設定。 此參數只會影響輸出訊息節流。 在 [每個 CPU 的進程內訊息] 設定中輸入 0 值，根據每個 CPU 的進程內訊息數目停用節流。 [每個 CPU 的進程內訊息] 設定的預設值為 1,000。 請注意，修改此值也會對訊息低延遲和/或 BizTalk 資源的效率造成影響。 如需詳細資訊，請參閱本主題中的 BizTalk High In-Process 訊息計數分析。 |
| Microsoft BizTalk Server：BizTalk 高訊息傳遞率 | 此分析會檢查高訊息傳遞率計數器中的值 1。 高訊息傳遞率可能是因為高處理複雜度、輸出配接器緩慢，或系統資源暫時不足所造成。 如需詳細資訊，請參閱本主題中的 BizTalk 高訊息傳遞速率分析。 |
| Microsoft BizTalk Server：BizTalk 高訊息發佈率 | 輸入主控件節流在 BizTalk Server 中也稱為訊息發佈節流，會套用至包含發佈訊息到 MessageBox 資料庫之接收配接器或協調流程的主控件執行個體。 此分析會檢查高訊息發佈速率計數器中的值 1。 如果發生這種情況，資料庫就無法跟上將訊息發佈至 BizTalk MessageBox 資料庫的速率。 參考： - 主機節流效能計數器 - 如何BizTalk Server實作主機節流 - 修改速率型節流設定 - 什麼是主機節流？ |
| Microsoft BizTalk Server：BizTalk 高進程記憶體 | 如果輸入 1 到 100 的值，BizTalk 進程記憶體使用量節流臨界值設定是所使用的記憶體百分比，相較于工作集大小和進程的總可用虛擬記憶體總和。 當指定某個百分比值時，則會以定期間隔重新計算程序記憶體閾值。 此分析會檢查高進程記憶體計數器中的值 1。 如需詳細資訊，請參閱本主題中的 BizTalk 高進程記憶體分析。 |
| Microsoft BizTalk Server：BizTalk 高系統記憶體 | 如果輸入 1 到 100 的值，BizTalk 實體記憶體使用量節流閾值設定是記憶體耗用量的百分比，相較于可用實體記憶體的總數量。 如果輸入大於 100 的值，此設定也可以是可用實體記憶體的總數量。 輸入值為 0 時可停用以實體記憶體使用量為基礎的節流。 預設值為 0。 如需詳細資訊，請參閱本主題中的 BizTalk 高系統記憶體分析。 |
| Microsoft BizTalk Server：BizTalk 高執行緒計數 | 「每個 CPU 的執行緒」是主機進程中的執行緒總數，包括介面卡所使用的執行緒。 如果超過此閾值，BizTalk Server會嘗試減少 EPM 執行緒集區和訊息代理程式執行緒集區的大小。 在高負載可能導致建立大量執行緒的情況時，應啟用以執行緒為基礎的節流。 此參數會同時影響輸入和輸出節流。 預設會停用執行緒型節流。 如需詳細資訊，請參閱本主題中的 BizTalk 高執行緒計數分析。 |
| Microsoft BizTalk Server：BizTalk 主機佇列長度 | BizTalk 主機佇列長度會追蹤特定主機佇列中的訊息總數。 您可以使用長度大小，例如 BizTalk：MessageBox：HostCounters：Host Queue – Length，藉由顯示個別主機的佇列深度，提供更詳細的訊息數目檢視。 此計數器在判斷特定主機是否瓶頸時很有用。 假設每個傳輸都使用唯一主機，這有助於判斷潛在的傳輸瓶頸。 此分析會檢查平均佇列長度是否大於 1。 主機佇列長度是加權佇列長度，方法是匯總目標主機的所有佇列 (工作 Q、狀態 Q、暫停的 Q) 記錄計數。 參考：BizTalk Server 2010：BizTalk Server效能測試方法 |
| Microsoft BizTalk Server：BizTalk 主機暫止訊息佇列長度 | 此計數器會追蹤特定主機的暫止訊息總數。 暫停的訊息是訊息或協調流程的實例，BizTalk Server因為系統或訊息中的錯誤而停止處理。 一般來說，因系統錯誤而擱置的執行個體會在系統問題獲得解決後繼續。 因訊息有問題而擱置的執行個體則通常無法繼續，且必須修正訊息本身並重新提交至 BizTalk Server 系統。 暫止訊息佇列是一個佇列，其中包含處理期間發生錯誤或失敗的工作專案。 訊息擱置佇列會儲存訊息直到修正和重新處理或是刪除後為止。 此分析會檢查是否有任何出現的暫止訊息。 增加的趨勢可能表示嚴重處理錯誤。 參考： - 監視BizTalk Server健全狀況和效能 - Microsoft BizTalk Server疑難排解 |
| BizTalk Server：BizTalk 閒置協調流程 | 目前由主控件執行個體裝載而閒置的協調流程執行個體數。 此計數器是指未進行進度但無法解除凍結的協調流程。 當協調流程遭到封鎖、等候接收、接聽或延遲不可部分完成的交易時，就會發生這種情況。 如果大量無法解除凍結的協調流程累積，BizTalk 可能會用盡記憶體。 凍結是將協調流程狀態序列化到 SQL Server 資料庫中的程序。 解除凍結是此程式的反向：從資料庫還原序列化協調流程的最後一個執行狀態。 凍結是藉由減少必須一次在記憶體中產生的協調流程數目，來將系統資源的使用降至最低。 引擎會儲存狀態以凍結執行個體，並釋出執行個體所需的記憶體。 透過凍結休眠的協調流程執行個體，引擎就可以讓大量的長時間執行之商務程序在相同電腦上同時執行。 此分析會檢查每小時一個閒置協調流程增加的趨勢。 參考： 協調流程解除凍結和解除凍結。 |
| BizTalk Server：BizTalk 輸入延遲 | 傳訊引擎從配接器收到檔到訊息箱發佈至 MessageBox 的時間，平均延遲以毫秒為單位。 減少延遲對 BizTalk 的某些使用者很重要，因此追蹤輸入配接器中花費多少時間檔很重要。 如需詳細資訊，請參閱本主題中的 BizTalk 輸入延遲分析。 |
| BizTalk Server：BizTalk 訊息傳遞延遲 | 這是目前延遲毫秒， (ms) 套用至每個訊息傳遞批次， (如果訊息傳遞正在進行節流) 則適用。 對於節流，視訊息為輸入或輸出而定，發佈或處理訊息時會套用延遲。 延遲期間會與節流條件的嚴重性成正比。 嚴重性節流條件的嚴重性節流條件會起始比嚴重性節流條件低的較長節流期間。 透過狀況變更時的節流機制，這個延遲期間可在特定範圍內上下調整。 目前的延遲期間會透過訊息傳遞延遲 (ms) 公開，而訊息發佈延遲 (ms) 與 BizTalk：Message Agent 效能物件類別相關聯的效能計數器。 此分析會檢查訊息傳遞延遲超過 5 秒。 長時間的訊息傳遞延遲可能會因為高負載而造成大量節流。 參考：如何BizTalk Server實作主機節流。 |
| BizTalk Server：BizTalk 訊息傳遞節流狀態 | BizTalk 訊息傳遞節流狀態是節流的主要指標之一。 這是旗標，指出系統是否正在節流訊息傳遞 (影響 XLANG 訊息處理和輸出傳輸) 。 節流條件是以計數器的數值表示。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息傳遞節流狀態分析。 |
| BizTalk Server：BizTalk 訊息發佈延遲 | 插入每個合格批次中的延遲，以節流發佈訊息。 對於節流，視訊息為輸入或輸出而定，發佈或處理訊息時會套用延遲。 延遲期間會與節流條件的嚴重性成正比。 嚴重性節流條件的嚴重性節流條件會起始比嚴重性節流條件低的較長節流期間。 透過狀況變更時的節流機制，這個延遲期間可在特定範圍內上下調整。 目前的延遲期間會透過訊息傳遞延遲 (ms) 公開，而訊息發佈延遲 (ms) 與 BizTalk：Message Agent 效能物件類別相關聯的效能計數器。 此分析會檢查訊息發佈延遲超過 5 秒。 長時間的訊息傳遞延遲可能會因為高負載而造成大量節流。 參考：如何BizTalk Server實作主機節流。 |
| BizTalk Server：BizTalk MessageBox 資料庫連線失敗 | 此效能計數器是自主機實例啟動後失敗的嘗試資料庫連結數目。 如果因為任何原因而無法使用裝載 BizTalk 資料庫的SQL Server服務，資料庫叢集會將資源從作用中電腦傳輸至被動電腦。 在此容錯移轉程序期間，BizTalk Server 服務執行個體發生資料庫連接失敗並自動重新啟動以重新連接到資料庫。 正在運作的資料庫電腦 (先前為被動電腦) 會在容錯移轉期間獲得資源後，開始處理資料庫連接。 如需詳細資訊，請參閱本主題中的 BizTalk MessageBox 資料庫連線失敗分析。 |
| BizTalk Server：BizTalk 傳訊延遲：要求回應延遲 | 傳訊引擎從配接器收到要求文件，到回應文件傳回該配接器之間的平均延遲 (毫秒)。 請參閱此圖表，此圖表顯示如何在 BizTalk 輸入延遲分析中測量延遲。 假設低延遲環境，此分析會檢查 Request-Response 延遲大於 5 秒。 這可能表示輸入介面卡與輸出配接器之間的處理延遲。 參考： - 要求/回應傳訊 - 調整您的解決方案 |
| BizTalk Server：BizTalk 傳訊發佈節流狀態 | BizTalk 訊息發佈節流狀態是節流的主要指標之一。 這是旗標，指出系統是否正在節流訊息發佈 (影響 XLANG 訊息處理和輸入傳輸) 。 如需詳細資訊，請參閱本主題中的 BizTalk 傳訊發佈節流狀態分析。 |
| BizTalk Server：BizTalk 協調流程暫停/秒 | 暫停的訊息是訊息或協調流程的實例，BizTalk Server因為系統或訊息中的錯誤而停止處理。 一般來說，因系統錯誤而擱置的執行個體會在系統問題獲得解決後繼續。 因訊息有問題而擱置的執行個體則通常無法繼續，且必須修正訊息本身並重新提交至 BizTalk Server 系統。 此分析會檢查是否有任何暫止的訊息/協調流程。 參考： - 監視BizTalk Server健全狀況和效能 - Microsoft BizTalk Server疑難排解 |
| BizTalk Server：BizTalk 協調流程已完成/秒 | 這是每秒完成的 BizTalk 協調流程數目。 這是 BizTalk 正在處理的輸送量的良好指標。 此分析僅提供統計資料。 參考： 調整您的解決方案 |
| BizTalk Server：已捨棄 BizTalk 協調流程 | 自從主控件執行個體啟動之後，已從記憶體捨棄的協調流程執行個體數。 如果引擎無法保存協調流程的狀態，即可予以捨棄。 此分析會檢查任何已捨棄的訊息。 參考： BizTalk Core Engine 的 WebLog |
| BizTalk Server：BizTalk 協調流程駐留在記憶體中 | 目前由主控件執行個體裝載的協調流程執行個體數。 此分析會檢查協調流程中駐留在記憶體中的趨勢增加，以及記憶體中駐留的協調流程是否超過 50%。 如需詳細資訊，請參閱位於記憶體分析中的 BizTalk 協調流程。 |
| BizTalk Server：BizTalk 輸出配接器延遲 | 這是介面卡從傳訊引擎取得檔到配接器傳送的時間前，平均延遲，以秒為單位。 請參閱此圖表，此圖表顯示如何在 BizTalk 輸入延遲分析中測量延遲。 假設低延遲環境，此分析會平均檢查輸出配接器中大於 5 秒的延遲。 這可能表示透過此主機實例的輸出配接器傳輸訊息的處理延遲。 如果此主機實例中有多個輸出配接器，請考慮將它們分成自己的主機，以判斷哪些輸出介面卡有高延遲。 參考： - 要求/回應傳訊。 - BizTalk Server 2006：在 BizTalk Server 2006 中使用 SOAP 配接器的延展性案例研究 - 識別 BizTalk 層中的瓶頸 - BizTalk Server的低延遲案例優化 |
| BizTalk Server：BizTalk 擱置訊息 | 尚未認可為已接收至 MessageBox 的已接收訊息數目。 暫止訊息是已提取至記憶體並傳遞至 XLANG 協調流程但尚未處理的訊息。 此情況與資料遺失無關。 將訊息傳遞至協調流程是一個多步驟程式，只是位於資料庫中多工緩衝處理資料表的訊息實例。 這些擱置中的訊息會計算為同進程訊息;因此，在記憶體中有大量的記憶體可能會造成系統上的記憶體節流。 調整 [內部訊息佇列大小] 設定有助於控制擱置的訊息數目。 In-Process 每個 CPU 的訊息設定會影響節流在發生大量擱置訊息時叫用的時間。 您可以在 BizTalk 管理主控台的 [主機] 屬性中找到這些設定。 此分析檢查只會顯示此計數器的統計資料。 參考： 協調流程引擎效能計數器。 |
| BizTalk Server：BizTalk 持續性點/秒 | 平均每秒保存的協調流程執行個體數。 協調流程引擎會在不同點儲存執行中協調流程執行個體的狀態。 如果它需要解除凍結協調流程實例、從受控制的關機啟動，或從非預期的關機復原，它會從最後一個持續性點執行協調流程實例。 為了保存協調流程實例，您的協調流程所參考的所有物件實例都會直接或間接 (，如同透過其他物件) 必須可序列化。 當訊息持續性頻率 (資料需要保存) 增加的次數時，整體效能會降低。 實際上，每個持續性點都是資料庫的來回行程，因此盡可能避免或合併持續性點來減少持續性點的頻率。 如需持續性點發生時機的詳細資訊，請參閱下列參考。 此分析會平均檢查每秒超過 10 個持續性點。 這是一般起點。 參考： - 協調流程中的持續性 - 持續性和協調流程引擎 |
| BizTalk Server：BizTalk 私人位元組 | 這是主機實例配置的私用記憶體 MB，相當於 「\Process (*) \Private Bytes」 效能計數器。 此分析會判斷任何主機實例是否耗用大量的系統記憶體，以及主機實例是否隨著時間增加記憶體耗用量。 如需詳細資訊，請參閱本主題中的 BizTalk 私人位元組分析。 |
| BizTalk Server：BizTalk 多工緩衝處理資料表大小 | MessageBox 多工緩衝處理資料表包含系統中每個訊息的記錄， (作用中或等候「垃圾收集」) 。 監視此資料表中的資料列數目，以及每秒收到的訊息數目，同時增加系統負載提供簡單的方式來尋找最大永續性輸送量。 只要增加輸入負載，直到 1 個) 多工緩衝處理資料表開始無限期成長，或) 每秒接收的訊息數目，不論第一個是哪一個，也就是您最大的永續輸送量。 總而言之，不論其他指標為何，此量值都會讓您快速且輕鬆地評估系統是否過度驅動。 當 BizTalk 多工緩衝處理資料表大小處於增加趨勢時，因為訊息傳遞速率不平衡， (輸入速率超出輸出速率，) 或資料庫大小所造成的節流。 此分析會檢查 BizTalk 多工緩衝處理資料表大小中的增加趨勢。 參考： - 瞭解 2004 SP1 輸送量和容量BizTalk Server - 永續性負載測試 - 測試引擎效能時的建議。 |
| BizTalk Server：BizTalk 追蹤資料大小 | 隨著BizTalk Server處理系統上更多資料，BizTalk 追蹤資料庫 (BizTalkDTADb) 會持續成長。 若未發現此成長現象將會降低系統效能，並且可能會在 Tracking Data Delivery Service (TDDS) 中產生錯誤。 除了一般追蹤資料以外，追蹤的訊息也會累積在 MessageBox 資料庫，導致磁碟效能變差。 此分析會檢查追蹤資料大小中每小時超過 5 MB 的趨勢。 參考： 封存和清除 BizTalk 追蹤資料庫 |
| BizTalk Server：BizTalk 交易範圍中止 | 這是自主機實例啟動後中止的長時間執行或不可部分完成的範圍數目。 交易範圍中止是在協調流程內的交易範圍內發生的失敗。 請務必瞭解，只有當範圍成功完成時，才會叫用範圍的補償處理常式，但必須復原，因為周圍範圍已決定中止 (，因為稍後可能會在程式中發生的失敗) 。 此外，當交易中止時，不會發生狀態的「自動」復原。 您可以透過例外狀況和補償處理常式，以程式設計方式達成此結果。 交易範圍中止通常不應該發生在生產環境中;因此，此分析會檢查是否中止任何交易範圍。 參考： 交易 |
| BizTalk Server：BizTalk 交易範圍補償 | 補償可視為已成功認可以回應某些錯誤狀況的工作邏輯復原。 請務必瞭解，只有當範圍成功完成時，才會叫用範圍的補償處理常式，但必須復原，因為周圍範圍已決定中止 (，因為稍後可能會在程式中發生的失敗) 。 此外，當交易中止時，不會發生狀態的「自動」復原。 您可以透過例外狀況和補償處理常式，以程式設計方式來達成這點。 交易範圍補償通常不應該發生在生產環境中;因此，此分析會檢查是否中止任何交易範圍。 參考： 交易 |
| BizTalk Server：BizTalk 虛擬位元組 | 這是保留給主機實例之虛擬記憶體的 MB。 此分析會判斷任何主機實例是否耗用大量的系統記憶體，以及主機實例是否隨著時間增加記憶體耗用量。 如需詳細資訊，請參閱本主題中的 BizTalk 虛擬位元組分析。 |
| BizTalk Server：BizTalk 訊息代理程式資料庫會話節流 | 相較于其個別的 BizTalk 節流設定，這是 MessageBox 開啟資料庫連結的數目。 「每個 CPU 的資料庫連線」是每個 CPU) 在節流開始之前允許的並行資料庫會話數目上限 (。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息代理程式資料庫會話節流分析。 |
| BizTalk Server：BizTalk 訊息代理程式資料庫會話節流閾值 | 這是 MessageBox 開啟資料庫連結數目的目前臨界值。 「每個 CPU 的資料庫連線」是每個 CPU) 在節流開始之前允許的並行資料庫會話數目上限 (。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息代理程式資料庫會話節流臨界值分析。 |
| BizTalk Server：BizTalk 訊息代理程式進程內訊息計數節流 | 這是服務類別正在處理的並行訊息數目。 主機節流設定中的「每個 CPU 處理訊息」設定是傳遞至端點管理員 (EPM) 或 XLANG 的訊息數目上限。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息代理程式進程訊息計數節流分析。 |
| BizTalk Server：BizTalk 訊息代理程式進程內訊息計數節流閾值 | 這是服務類別正在處理的並行訊息數目目前的臨界值。 主機節流設定中的「每個 CPU 處理訊息」設定是傳遞至端點管理員 (EPM) 或 XLANG 的訊息數目上限。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息代理程式進程內訊息計數節流臨界值分析。 |
| BizTalk Server：BizTalk 訊息代理程式處理記憶體使用量 (MB) 節流 | 這是目前進程 (MB) 的記憶體使用量。 如果要發佈的批次有尖峰的記憶體需求，或太多執行緒正在處理訊息，則會發生 BizTalk 進程記憶體節流。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息代理程式處理記憶體使用量 (MB) 節流分析。 |
| BizTalk Server：BizTalk 訊息代理程式處理記憶體使用量 (MB) 節流閾值 | 這是目前進程記憶體使用量的目前閾值， (MB) 。 視此進程的實際可用記憶體數量及其記憶體耗用量模式而定，閾值可能會動態調整。 如果要發佈的批次有尖峰的記憶體需求，或太多執行緒正在處理訊息，則會發生 BizTalk 進程記憶體節流。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息代理程式處理記憶體使用量 (MB) 節流臨界值分析。 |
| BizTalk Server：BizTalk 訊息代理程式執行緒計數節流 | BizTalk 進程中的執行緒總數。 「每個 CPU 的執行緒」是主機進程中的執行緒總數，包括介面卡所使用的執行緒。 若超過此閾值，BizTalk Server 會嘗試減少 EPM 執行緒集區和訊息代理程式執行緒集區的大小。 在高負載可能導致建立大量執行緒的情況時，應啟用以執行緒為基礎的節流。 此參數會同時影響輸入和輸出節流。 預設會停用執行緒型節流。 此分析會檢查 BizTalk 執行緒計數是否大於 80% 的節流臨界值，指出節流條件可能是。 參考： - 主機節流效能計數器 - 如何BizTalk Server實作主機節流 - 如何修改預設主機節流設定 - 影響配接器效能的組態參數 - 執行緒、DB 會話和節流 |
| BizTalk Server：BizTalk 訊息代理程式執行緒計數節流閾值 | 這是進程中線程總數的目前臨界值。 「每個 CPU 的執行緒」是主機進程中的執行緒總數，包括介面卡所使用的執行緒。 若超過此閾值，BizTalk Server 會嘗試減少 EPM 執行緒集區和訊息代理程式執行緒集區的大小。 在高負載可能會導致大量執行緒建立的情況下，應該啟用執行緒型節流。 此參數會同時影響輸入和輸出節流。 此分析會檢查此節流設定是否設定為非預設值。 預設會停用執行緒型節流。 參考： - 主機節流效能計數器 - 如何BizTalk Server實作主機節流 - 如何修改預設主機節流設定 - 影響配接器效能的組態參數 - 執行緒、DB 會話和節流 |
邏輯/實體磁片讀取/寫入延遲分析
Windows 偵測磁片效能瓶頸的最可靠方式是測量其回應時間。 如果回應時間大於 .025 (25 毫秒) ，這是保守的臨界值，則可能會影響使用者的明顯緩慢和效能問題可能會發生。
磁片延遲不佳的常見原因是磁碟片段、效能快取、過度飽和的 SAN，以及磁片上的負載過多。 使用 SPA 工具來協助識別使用磁片的頂端檔案和進程。 另請檢查「處理 IO 資料作業/秒」和「處理 IO 其他作業/秒」，以查看哪些進程耗用最多磁片 I/O。 請記住，效能監視器計數器無法指定涉及哪些檔案。
參考資料
邏輯磁片傳輸/秒
「磁片傳輸/秒」是磁片上讀取和寫入作業的速率。 雖然磁片傳輸不是與磁片 I/O 的直接相互關聯，但確實會告訴我們有多少磁片作業發生。 如果您平均出循序 I/O 和隨機 I/O 的 ，則最後您最後會以一般經驗法則表示每秒大約 80 個 I/O。 因此，當負載不足時，我們應該預期 SAN 磁片磁碟機每秒執行超過 80 個 I/O。 此分析的臨界值會檢查是否有任何邏輯磁片顯示回應時間不佳， (I/O 作業) 大於 25 毫秒的回應時間。 如果這是 true，則我們應該預期每秒的磁片傳輸會位於或高於 80。 如果沒有，則必須調查磁片架構。 磁片 I/O 不佳最常見的原因是在 SAN 上 (LUN) 多載的邏輯單元編號，這表示多個 LUN 使用小型實體磁片陣列的條件。
可用的記憶體分析
「Available Mbytes」 是電腦上執行之進程的可用實體記憶體數量，以 MB 為單位。 Virtual Memory Manager 會持續調整實體記憶體和磁片上所使用的空間，以維護作業系統和進程的可用位元組數目下限。 當可用的位元組很豐富時，Virtual Memory Manager 可讓進程的工作集成長，或藉由移除新增的每個新頁面的舊頁面來保持穩定。 當可用的位元組很少時，Virtual Memory Manager 必須修剪工作集，以維持所需的最低需求。
此分析會檢查可用記憶體總計是否偏低 – 10% 可用的警告，以及 5% 可用的嚴重性。 當偵測到每小時 10 MB 的減少趨勢時，也會發出警告，指出可能即將發生的記憶體狀況。 低實體記憶體可能會導致特殊許可權模式 CPU 和系統延遲增加。
參考資料
記憶體流失偵測分析
此分析會判斷任何進程是否耗用大量的系統記憶體，以及進程是否隨著時間而增加記憶體耗用量。 只要進程將記憶體傳回至系統，就可以使用大量記憶體的進程。 尋找圖表中的增加趨勢。 長時間增加的趨勢可能表示記憶體流失。 Private Bytes 是這個進程所配置且無法與其他進程共用的目前大小，以位元組為單位。 此分析會檢查每小時 10 MB，以及每小時增加 5 MB 的趨勢。 將此分析與可用的記憶體分析相互關聯。
此外，請記住，新啟動的進程一開始會在只是正常啟動行為時顯示為記憶體流失。 當進程繼續耗用記憶體，且不會長時間釋放記憶體時，就會發生記憶體流失。
如果您懷疑記憶體流失狀況，請安裝並使用偵錯診斷工具。 如需偵錯 Diag 工具的詳細資訊，請參閱參考一節。
參考
Memory Pages/sec Analysis
此分析會檢查 「Pages/sec」 是否很高。 如果很高，則系統可能藉由嘗試將記憶體分頁至磁片而用盡。 「Pages/sec」 是頁面讀取或寫入磁片以解決硬式分頁錯誤的速率。 此計數器是導致整個系統延遲這類錯誤的主要指示器。 這是 「Memory\Pages Input/sec」 和 「Memory\Pages Output/sec」 的總和。 它會以頁數計算，因此可以與其他頁面計數進行比較，例如「Memory\Page Faults/sec」。
此計數器應一律低於 1,000。 此分析會檢查高於 1,000 的值。 將此分析與可用的記憶體分析和記憶體流失偵測分析相互關聯。 如果所有分析同時擲回警示，這可能表示系統記憶體不足。 請遵循本主題中有關記憶體流失偵測分析的其他資訊中所述的分析步驟。
參考
記憶體系統快取駐留位元組分析
「系統快取駐留位元組」是檔案系統快取中可分頁作業系統程式碼的大小，以位元組為單位。 這個值只包含目前的實體分頁，而不包含任何非目前駐留的虛擬記憶體分頁。 它等於工作管理員中顯示的系統快取值。 因此，此值可能會小於檔案系統快取使用中的實際虛擬記憶體數量。 這個值是 「Memory\\System Code Resident Bytes」 的元件，代表目前在實體記憶體中的所有可分頁作業系統程式碼。 此計數器只會顯示最後的觀察值；它不是平均值。
此分析會檢查每小時增加 10 MB 的趨勢。 在負載下，伺服器可能會使用系統快取來快取 I/O 活動，例如磁片。 與處理 IO 資料作業/秒和處理 IO 其他作業/秒分析相互關聯。
處理器使用率分析和進程過度使用的處理器
「% 處理器時間」 是處理器花費來執行非閒置執行緒所耗用時間的百分比。 其計算方式是測量閒置執行緒在取樣間隔作用中的持續時間，然後從間隔持續時間減去該時間。 (當沒有其他執行緒準備好執行時，每個處理器都有一個閒置執行緒，會耗用迴圈。) 此計數器是處理器活動的主要指標，並顯示取樣間隔期間觀察到的平均忙碌時間百分比。 其計算方式是監視服務非使用中的時間，並將該值從 100% 減去。
此分析會檢查每個個別處理器的使用率是否大於 60%。 如果是，請判斷其為高使用者模式 CPU 或高特殊許可權模式。 如果懷疑高特殊許可權模式 CPU，請參閱「特殊許可權模式 CPU 分析」。 如果懷疑使用者模式處理器瓶頸，請考慮使用進程分析工具來分析造成高 CPU 耗用量的函式。 See “How To: Identify Functions causing a High User-mode CPU Bottleneck for Server Applications in a Production Environment” article in the references section for more information.
處理器佇列長度分析
「處理器佇列長度」是處理器佇列中的執行緒數目。 不同於磁碟計數器，此計數器僅顯示準備就緒的執行緒，而不包括執行中的執行緒。 處理器時間僅有單一佇列，即使是具有多處理器的電腦也是一樣。 因此，如果電腦具有多個處理器，便需要將此值除以處理工作負載的處理器個數。 每個處理器佇列持續少於 10 個執行緒通常可以接受，視工作負載而定。
此分析會判斷平均處理器佇列長度是否超過處理器數目。 若是如此，這可能表示處理器瓶頸。 將此分析與特殊許可權模式 CPU 分析和進程過度使用的處理器相互關聯。 處理器佇列是執行緒的集合，這些執行緒已就緒，但無法由處理器執行，因為目前正在執行另一個作用中的執行緒。 比處理器數目更多的執行緒持續或週期性佇列是處理器瓶頸的良好指示。
您可以將此計數器與 「Processor\% Processor Time」 計數器搭配使用，以判斷您的應用程式是否可以受益于更多 CPU。 處理器時間有單一佇列，即使在多處理器電腦上也是如此。 因此，在多處理器電腦中，將「處理器佇列長度」 (PQL) 值除以維護工作負載的處理器數目
如果 CPU 非常忙碌， (90% 和更高的使用率) 且 PQL 平均值一致高於處理器數目，則您可能會有可能受益于其他 CPU 的處理器瓶頸。 或者，您可以減少應用層級的執行緒和佇列數目。 這會導致較少的內容切換，這很適合用來減少 CPU 負載。 高 CPU 使用率偏高 PQL 的常見原因是處理器時間的要求隨機抵達，而執行緒要求處理器的時間量不規則。 這表示處理器不是瓶頸。 相反地，需要改善的執行緒邏輯。
如果懷疑使用者模式處理器瓶頸，請考慮使用進程分析工具來分析造成高 CPU 耗用量的函式。 See the “How To: Identify Functions causing a High User-mode CPU Bottleneck for Server Applications in a Production Environment” article in the references section for more information.
特殊許可權模式 CPU 分析
此計數器指出執行緒以特殊許可權模式執行的時間百分比。 當您的應用程式呼叫作業系統函式 (例如執行檔案或網路 I/O 或配置記憶體) 時，這些作業系統函式會以特殊許可權模式執行。
高特殊許可權模式 CPU 表示電腦在系統 I/O 與實際 (使用者模式) 工作時花費太多時間。 「% Privileged Time」 是進程執行緒花費在特殊許可權模式中執行程式碼所耗用時間的百分比。 呼叫 Windows 系統服務時，服務通常會以特殊許可權模式執行，以取得系統私人資料的存取權。 這類資料會受到在使用者模式中執行的執行緒存取保護。 呼叫系統時可以採用明確或隱含方式，例如分頁錯誤或中斷。 不同于某些早期作業系統，除了使用者和特殊許可權模式的傳統保護之外，Windows 還會使用進程界限來保護子系統。 除了進程的特殊許可權時間之外，Windows 代表應用程式完成的部分工作可能會出現在其他子系統進程中。
此分析會檢查特殊許可權模式 CPU 是否耗用超過總 CPU 的 30%。 如果是，則 CPU 耗用量可能是因為處理器以外的另一個瓶頸所造成，例如網路、記憶體或磁片 I/O。 與 % 停機時間和高內容切換分析相互關聯。
高內容切換分析
當優先順序較高的執行緒優先佔用目前正在執行的較低優先順序執行緒，或高優先順序執行緒封鎖時，就會發生內容切換。 當許多執行緒共用相同的優先順序層級時，可能會發生高層級的內容切換。 這通常表示太多執行緒在系統上競爭處理器。 如果您沒有看到太多處理器使用率，而且看到非常低的內容切換層級，表示執行緒遭到封鎖。
只有在特殊許可權模式 CPU 和整體 CPU 偏高時，才應該調查高內容切換。 一般規則是，每個處理器每秒小於 5,000 次的內容切換速率並不值得擔心。 如果每個處理器的內容切換速率超過每秒 15,000，則有一個條件約束。
此分析會檢查高 CPU、高特殊許可權模式 CPU，以及每個處理器大於 5,000 個的高 (，) 系統內容交換器每秒都同時發生。 如果發生高內容切換，請減少系統上執行的執行緒和進程數目。
BizTalk 高資料庫會話分析
此計數器有兩個可能的值，也就是一般 (0) 或超過 (1) 。 此分析會檢查值 1。 如果是，BizTalk 已超過允許的資料庫會話數目閾值。 此值是由 BizTalk 主機節流設定中的「每個 CPU 的資料庫連線」值所控制。
「每個 CPU 的資料庫連線」是節流開始之前，每個 CPU) 允許的並行資料庫會話數目上限 (。 一般個別主控件工作階段集區中的閒置資料庫工作階段不會加到此計數，而是對主控件執行個體實際正在使用的工作階段數目嚴格執行這項檢查。 此選項預設為停用;通常，只有在資料庫伺服器是瓶頸或BizTalk Server系統中的低階資料庫伺服器時，才應該啟用此設定。 您可以使用 BizTalk：Message Agent 效能物件類別之下的資料庫會話效能計數器來監視作用中資料庫連結的數目。 此參數只會影響輸出訊息節流。 輸入值為 0 時可停用以資料庫工作階段數目為基礎的節流。 預設值為 0。
注意
「MaxWorkerThreads」 登錄機碼會影響 BizTalk 可用的執行緒數目，而且如果大部分的 BizTalk 執行緒忙碌資料庫連結，可能會有所説明。
參考資料
BizTalk 高資料庫大小分析
此計數器是指此進程已發佈的資料庫佇列中的訊息數目。 這個值是由所有主控件的佇列表格中之項目數目以及多工緩衝處理與追蹤表格中的項目數目來測量。 佇列包含工作佇列、狀態佇列和暫停的佇列。 若程序正發佈到多個佇列，則此計數器會反映所有佇列的加權平均值。
若重新啟動主控件，則會遺失保留在記憶體中的統計值。 由於牽涉到某些額外負荷，BizTalk Server只有在至少有 100 個發行時，才會繼續收集統計資料，而重新開機主機進程內總計發行的 5%。
如果發生資料庫閾值中訊息計數列出的任一條件，此計數器將會設定為 1。 此閾值記載于下列如何修改預設主機節流設定主題中。 根據預設，資料庫節流閾值中的主機訊息計數設定為 50,000，這會在下列情況下觸發節流條件：
主控件執行個體發佈到訂閱之主控件的工作、狀態和擱置佇列的訊息總數超過 50,000。
多工緩衝處理表格或追蹤表格中的訊息數目超過 50,000 個訊息。
由於暫停的訊息會包含在資料庫計算中的訊息計數中，因此即使 BizTalk 伺服器遇到低或無負載，訊息發佈也會發生節流。
此分析會檢查值 1。 如果發生這種情況，請考慮一個動作，以減少資料庫中的訊息數目。 例如，請確定 BizTalk SQL Server作業執行時不會發生錯誤，並使用 BizTalk 管理主控台中的群組中樞來判斷訊息組建是否由大量暫止的訊息所造成。
參考資料
BizTalk 高 In-Process 訊息計數分析
主機節流設定中的「每個 CPU 進程訊息」設定是傳遞至端點管理員的訊息數目上限， (EPM) 或 XLANG。 此數目不包含從資料庫擷取的訊息，但仍在記憶體內部佇列中等候傳遞。 您可以使用 BizTalk：Message Agent 效能物件類別下的進程內訊息計數效能計數器來監視進程內訊息的數目。 此參數會在考慮節流條件時，提供節流機制的提示。 實際閾值會受自我調整影響而不同。 您可以監視進程訊息計數效能計數器來驗證實際閾值。
這個參數可以設定為較小的大型訊息案例值，其中平均訊息大小很高，或訊息的處理可能需要大量訊息。 如果案例太常發生以記憶體為基礎的節流，而且記憶體閾值會自動調整為大幅較低的值，則這很明顯。 此類行為發生時表示輸出傳輸應減少同時處理的訊息數，以避免過度使用記憶體。 此外，對於一次處理少量訊息可讓配接器較有效率的實例 (例如，傳送至限制並行連線的伺服器時)，此參數可調整為低於預設的值。
此分析會檢查高 In-Process 訊息計數計數器，以判斷是否正在發生這種節流。 若是如此，請考慮調整 [每個 CPU 的進程內訊息] 設定。 此參數只會影響輸出訊息節流。 在 [每個 CPU 的進程內訊息] 設定中輸入 0 的值，以根據每個 CPU 的進程內訊息數目停用節流。 [每個 CPU 的進程內訊息] 設定的預設值為 1,000。 請注意，修改此值也會對訊息的低延遲和/或 BizTalk 資源的效率造成影響。
參考資料
BizTalk 高訊息傳遞率分析
針對傳遞的輸出 () 訊息，如果主機實例的訊息傳遞速率超過訊息傳遞率 * 指定的速率超驅因素， (百分比) 值，則BizTalk Server節流傳遞訊息。 在 [訊息處理節流設定] 對話方塊上，可設定 (百分比) 參數的速率超驅因素。 輸出訊息的速率型節流主要是藉由在從記憶體內部佇列中移除訊息並傳遞訊息至 EPM) 或協調流程引擎之前，先產生延遲，再將訊息傳遞至端點管理員 (EPM) 或協調流程引擎來處理。 不會採取任何其他動作來完成輸出訊息的速率型節流。
輸出節流會造成訊息延遲傳遞，而且訊息可能建立在記憶體中佇列內，並造成清除佇列執行緒遭到封鎖，直到移轉了節流狀況為止。 當解除佇列執行緒遭到封鎖時，不會從 MessageBox 將其他訊息提取到記憶體內部佇列以進行輸出傳遞。
此分析會檢查高訊息傳遞率計數器中的值 1。 高訊息傳遞率可能是因為高處理複雜度、輸出介面卡緩慢，或系統資源暫時不足所造成。
參考資料
BizTalk 高進程記憶體分析
如果輸入 1 到 100 的值，BizTalk 進程記憶體使用量節流閾值設定是所使用的記憶體百分比，相較于工作集大小和進程可用虛擬記憶體總數的總和。 根據預設，BizTalk 進程記憶體使用量節流設定為 25。 當指定某個百分比值時，則會以定期間隔重新計算程序記憶體閾值。 如果使用者指定百分比值，則會根據要認可的可用記憶體和目前的進程記憶體使用量來計算。
此分析會檢查高進程記憶體計數器中的值 1。 如果發生這種情況，請嘗試使用偵錯診斷來判斷記憶體增加的原因， (請參閱記憶體流失偵測分析) 中的參考。 請注意，當進程無法釋放不再需要的記憶體時，進程通常會在啟動期間耗用大量的記憶體，這一開始可能會顯示為記憶體流失，但當進程無法釋放不再需要的記憶體時，就會發生真正的記憶體流失，進而減少一段時間的可用記憶體數量。 如需如何在 BizTalk 中一般分析進程記憶體流失的詳細資訊，請參閱下方的參考和/或 PAL 中的「記憶體流失偵測」分析。
如果要發行的批次有較高的記憶體需求，或太多執行緒正在處理訊息，可能會發生高進程記憶體節流。 如果系統似乎過度節流，請考慮增加與主機進程記憶體使用量閾值相關聯的值，並確認主機實例不會產生「記憶體不足」錯誤。 如果增加進程記憶體使用量閾值而引發「記憶體不足」錯誤，請考慮減少每個 CPU 閾值的內部訊息佇列大小和進程內訊息的值。 此策略特別會與大型訊息處理實例有關。 此外，對於每個訊息具有大型記憶體需求的案例，此值應該設定為低值。 設定低值會提早進行節流，並防止進程內的記憶體暴增。
如果您的 BizTalk 伺服器定期用盡虛擬記憶體，請考慮BizTalk Server 64 位。 64 位伺服器上的每個進程最多可以處理 4 TB 的虛擬記憶體，而不是 32 位中的 2 GB。 一般而言，強烈建議使用 64 位 BizTalk 和 64 位SQL Server。 See the “BizTalk Server 64-bit Support” reference for more information.
參考資料
BizTalk 高系統記憶體分析
如果輸入 1 到 100 的值，BizTalk 實體記憶體使用量節流閾值設定是記憶體耗用量的百分比，相較于可用實體記憶體的總數量。 如果輸入大於 100 的值，此設定也可以是可用實體記憶體的總數量。 輸入值為 0 時可停用以實體記憶體使用量為基礎的節流。 預設值為 0。
此分析會檢查高系統記憶體計數器中的值 1。 因為這會測量系統記憶體總量，若非 BizTalk Server 程序正耗用過量的系統記憶體，則可能觸發節流狀況。 因此，如果發生這種情況，最佳方法是識別哪些進程耗用最多實體記憶體和/或將額外的實體記憶體新增至伺服器。 此外，請考慮減少 EPM 執行緒集區的預設大小，以及/或介面卡批次的大小來減少負載。 如需詳細資訊，請參閱 PAL 中的記憶體流失偵測分析。
參考資料
BizTalk 高執行緒計數分析
「每個 CPU 的執行緒」是主機進程中的執行緒總數，包括介面卡所使用的執行緒。 如果超過此閾值，BizTalk Server會嘗試減少 EPM 執行緒集區和訊息代理程式執行緒集區的大小。 在高負載可能導致建立大量執行緒的情況時，應啟用以執行緒為基礎的節流。 此參數會同時影響輸入和輸出節流。 預設會停用執行緒型節流。
注意
使用者指定的值會作為指導方針使用，而且主機可能會根據進程的記憶體使用量模式和執行緒需求，動態自行調整此臨界值。
此分析會檢查高執行緒計數計數器中的值為 1。 考慮調整不同的執行緒集區大小，以確定系統不會建立大量的執行緒。 此分析可以與每秒內容交換器分析相互關聯，以判斷作業系統是否飽和太多執行緒，但在大多數情況下，高執行緒計數在後端資料庫上會造成比 BizTalk 伺服器上更多的爭用。 如需修改執行緒集區大小的詳細資訊，請參閱如何修改參考中的預設主機節流設定。
參考資料
-
BizTalk 輸入延遲分析從傳訊引擎收到配接器的檔到發佈至訊息方塊的時間，以毫秒為單位的延遲。 減少延遲對 BizTalk 的某些使用者很重要，因此追蹤輸入配接器中花費多少時間檔很重要。
以下是顯示如何測量延遲的圖表。
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| 配接器會接收訊息，並將它提交至引擎，在將訊息提供給這些效能計數器中未擷取的引擎之前，先在配接器中完成工作 | 引擎會從配接器接收訊息、執行接收管線、對應、訂用帳戶評估、保存 DB 中的訊息。 | 協調流程或 Solicit-Response 埠會執行並產生回應訊息。 | 回應訊息會在訊息引擎中取消佇列，執行傳送管線對應。 | 傳訊引擎會提供配接器的回應訊息。 | 配接器會通知引擎訊息已完成。 |
| I | |||||
| Rr | Rr | Rr | |||
| O | O | O | |||
| OA | OA |
I = 輸入延遲
RR = 要求回應延遲
O = 輸出延遲
OA = 輸出配接器延遲
假設低延遲環境，此分析會檢查檔是否在輸入配接器中花費超過 5 秒。 這可能表示透過此主機實例的輸入配接器傳輸訊息的處理延遲。 如果此主機實例中有多個輸入介面卡，請考慮將它們分成自己的主機，以判斷哪一個輸入介面卡有高延遲。
參考資料
BizTalk 訊息傳遞節流狀態分析
BizTalk 訊息傳遞節流狀態是節流的主要指標之一。 這是旗標，指出系統是否正在節流訊息傳遞 (影響 XLANG 訊息處理和輸出傳輸) 。 節流條件是以計數器的數值表示。 以下是值的清單及其各自的意義：
| 節流條件 | 描述 |
|---|---|
| 0 | 未進行節流 |
| 1 | 由於不平衡的訊息傳遞速率 (輸入速率超過輸出速率) 而進行節流 |
| 3 | 由於高內含式訊息計數而進行節流 |
| 4 | 由於處理程序記憶體壓力而進行節流 |
| 5 | 由於系統記憶體壓力而進行節流 |
| 9 | 由於高執行緒計數而進行節流 |
| 10 | 由於傳遞時使用者覆寫而進行節流 |
此分析會檢查每個值，並針對每個值都有特定的警示。
參考資料
BizTalk MessageBox 資料庫連線失敗分析
此效能計數器是自主機實例啟動後失敗的嘗試資料庫連結數目。 如果因為任何原因而無法使用裝載 BizTalk 資料庫的SQL Server服務，資料庫叢集會將資源從作用中電腦傳輸至被動電腦。 在此容錯移轉程序期間，BizTalk Server 服務執行個體發生資料庫連接失敗並自動重新啟動以重新連接到資料庫。 正在運作的資料庫電腦 (先前為被動電腦) 會在容錯移轉期間獲得資源後，開始處理資料庫連接。
當BizTalk Server執行時間無法與 MessageBox 或管理資料庫通訊時，DBNetLib (資料庫) 發生錯誤。 發生這種情況時，BizTalk Server攔截例外狀況的執行時間實例會關閉，然後每分鐘迴圈一次，以查看資料庫是否可用。 如需本主題的詳細資訊，請參閱參考一節。
當用戶端起始 TCP/IP 通訊端連線聯繫伺服器時，用戶端通常會連接到伺服器上特定的連接埠，並要求伺服器透過短期有效的臨時 TCP 或 UDP 連接埠回應用戶端。 在 Windows Server 2003 和 Windows XP 上，用戶端應用程式所使用的暫時埠預設範圍是從 1025 到 5000。 在某些情況下，預設範圍內的可用埠可能會耗盡。 如需本主題的詳細資訊，請參閱參考一節。
此分析會檢查是否有任何發生資料庫連線失敗的問題。 資料庫連線失敗很重要，因為 BizTalk 無法在沒有資料庫的情況下運作。 如果資料庫連線失敗的原因不明，請考慮下列和/或連絡人Microsoft 支援服務的參考，以判斷連線失敗的本質。
參考資料
BizTalk 傳訊發佈節流狀態分析
BizTalk 訊息發佈節流狀態是節流的主要指標之一。 這是旗標，指出系統是否正在節流訊息發佈 (影響 XLANG 訊息處理和輸入傳輸) 。節流條件是以計數器的數值表示。 以下是值的清單及其各自的意義：
| 節流條件 | 描述 |
|---|---|
| 0 | 未進行節流 |
| 2 | 由於不平衡的訊息發佈速率 (輸入速率超過輸出速率) 而進行節流 |
| 4 | 由於處理程序記憶體壓力而進行節流 |
| 5 | 由於系統記憶體壓力而進行節流 |
| 6 | 由於資料庫成長而進行節流 |
| 8 | 由於高工作階段計數而進行節流 |
| 9 | 由於高執行緒計數而進行節流 |
| 11 | 由於發佈時使用者覆寫而進行節流 |
此分析會檢查每個值，並針對每個值都有特定的警示。
參考資料
BizTalk 協調流程位於記憶體中
目前由主控件執行個體裝載的協調流程執行個體數。 雖然駐留在記憶體中的協調流程尖峰或高載可能會被視為正常，但增加的趨勢可能表示記憶體中協調流程的「堆積」。 當 BizTalk 無法解除凍結訊息/協調流程實例時，可能會隨著時間增加的趨勢。 嘗試將此計數器與 「XLANG/s Orchestrations (？) \Dehydratable 協調流程」相互關聯，其中問號 (？) 與此計數器相同。
如果大量的協調流程位於記憶體中，而且如果可解除凍結的協調流程數目很低，則您的協調流程可能會閒置在記憶體中，而且可能會導致記憶體流失狀況。 如果存在，請使用此分析與 「\XLANG/s Orchestrations (*) \Idle 協調流程」 相互關聯。 BizTalk 閒置協調流程中的增加趨勢是記憶體流失的較佳指標，因為無法解除凍結協調流程實例。
此分析會檢查協調流程中駐留在記憶體中的趨勢增加，以及如果記憶體中存在超過 50% 的協調流程無法解除凍結。
參考資料
BizTalk 私人位元組分析
這是主機實例配置的私用記憶體 MB，相當於 「\Process (*) \Private Bytes」 效能計數器。 Private Bytes 是進程所配置且無法與其他進程共用的目前大小，以位元組為單位。 此分析會判斷任何主機實例是否耗用大量的系統記憶體，以及主機實例是否隨著時間增加記憶體耗用量。 只要主機實例將記憶體傳回系統，耗用大量記憶體的主機實例就沒問題。 尋找圖表中的增加趨勢。 長時間增加的趨勢可能表示記憶體流失。
此分析會檢查每小時增加 10 MB 的趨勢。 使用此分析與可用的記憶體分析和記憶體流失分析相互關聯。 此外，請記住，剛啟動的主機實例一開始會在只是正常啟動行為時顯示為記憶體流失。 記憶體流失是進程繼續耗用記憶體，而不會在長時間內釋放記憶體時。 如果您懷疑記憶體流失狀況，請閱讀以下所參考的「BizTalk 傳訊中的記憶體成長」一文。 否則，請安裝和使用 [偵錯診斷] 工具。 如需偵錯診斷工具的詳細資訊，請參閱參考一節。
參考資料
BizTalk 虛擬位元組分析
這是保留給主機實例之虛擬記憶體的 MB。 此分析會判斷任何主機實例是否耗用大量的系統記憶體，以及主機實例是否隨著時間增加記憶體耗用量。 只要主機實例將記憶體傳回系統，耗用大量記憶體的主機實例就沒問題。 尋找圖表中的增加趨勢。 長時間增加的趨勢可能表示記憶體流失。
此分析會檢查虛擬位元組中每小時增加 10 MB 的趨勢。 使用此分析與可用的記憶體分析和記憶體流失分析相互關聯。 此外，請記住，剛啟動的主機實例一開始會在只是正常啟動行為時顯示為記憶體流失。 記憶體流失是進程繼續耗用記憶體，而不會在長時間內釋放記憶體時。 如果您懷疑記憶體流失狀況，請閱讀下面的「BizTalk 傳訊中的記憶體成長」文章。 否則，請安裝和使用 [偵錯診斷] 工具。 如需偵錯診斷工具的詳細資訊，請參閱參考一節。
參考資料
BizTalk 訊息代理程式資料庫會話節流分析
相較于其個別的 BizTalk 節流設定，這是 MessageBox 開啟資料庫連結的數目。 「每個 CPU 的資料庫連線」是每個 CPU) 在節流開始之前允許的並行資料庫會話數目上限 (。 一般個別主控件工作階段集區中的閒置資料庫工作階段不會加到此計數，而是對主控件執行個體實際正在使用的工作階段數目嚴格執行這項檢查。 此選項預設為停用；通常只有在資料庫伺服器是 BizTalk Server 系統中的瓶頸時，才應啟用此設定。 您可以使用 BizTalk：Message Agent 效能物件類別下的資料庫會話效能計數器來監視作用中資料庫連結的數目。 此參數只會影響輸出訊息節流。 輸入值為 0 時可停用以資料庫工作階段數目為基礎的節流。 預設值為 0。
MaxWorkerThreads 登錄機碼會影響 BizTalk 可用的執行緒數目，而且在大部分 BizTalk 的執行緒忙碌資料庫連結的情況下，可能會有所説明。 此分析會檢查 MessageBox 的開啟資料庫連結數目是否大於資料庫會話節流設定的 80%，指出節流條件可能是。
參考資料
BizTalk 訊息代理程式資料庫會話節流臨界值分析
這是 MessageBox 開啟資料庫連結數目的目前臨界值。 「每個 CPU 的資料庫連線」是每個 CPU) 在節流開始之前允許的並行資料庫會話數目上限 (。 一般個別主控件工作階段集區中的閒置資料庫工作階段不會加到此計數，而是對主控件執行個體實際正在使用的工作階段數目嚴格執行這項檢查。 此選項預設為停用；通常只有在資料庫伺服器是 BizTalk Server 系統中的瓶頸時，才應啟用此設定。 您可以使用 BizTalk：Message Agent 效能物件類別下的資料庫會話效能計數器來監視作用中資料庫連結的數目。 此參數只會影響輸出訊息節流。 輸入值為 0 時可停用以資料庫工作階段數目為基礎的節流。 預設值為 0。
MaxWorkerThreads 登錄機碼會影響 BizTalk 可用的執行緒數目，而且在大部分 BizTalk 的執行緒忙碌資料庫連結的情況下，可能會有所説明。 此分析會檢查此值，以查看是否已從預設值修改此值。 根據預設，此設定為 0，這表示已停用資料庫會話的節流。
參考資料
BizTalk 訊息代理程式進程內訊息計數節流分析
這是服務類別正在處理的並行訊息數目。 主機節流設定中的「每個 CPU 處理訊息」設定是傳遞至端點管理員 (EPM) 或 XLANG 的訊息數目上限。 這不包含從資料庫擷取但仍在等候記憶體內部佇列中傳遞的訊息。 您可以使用 BizTalk：Message Agent 效能物件類別下的進程內訊息計數效能計數器來監視進程內訊息的數目。 此參數提供提示給節流機制，做為節流狀況的考量。 實際閾值會受自我調整影響而不同。 您可以監控 [內含式訊息計數] 效能計數器，以確認實際閾值。
對於大型訊息案例 (其中平均訊息大小很高，或訊息處理可能需要大量訊息) ，此參數可以設定為較小的值。 指出大型訊息案例是否太常發生記憶體型節流，以及記憶體臨界值是否自動調整為大幅低的值。 此類行為發生時表示輸出傳輸應減少同時處理的訊息數，以避免過度使用記憶體。 此外，對於一次處理少量訊息可讓配接器較有效率的實例 (例如，傳送至限制並行連線的伺服器時)，此參數可調整為低於預設的值。 此分析會檢查 [高] In-Process [訊息計數] 計數器，以判斷其節流設定是否在相同名稱下大於 80%，這表示節流條件可能是。
參考資料
BizTalk：訊息代理程式進程內訊息計數節流臨界值分析
這是服務類別正在處理的並行訊息數目目前的臨界值。 主機節流設定中的「每個 CPU 處理訊息」設定是傳遞至端點管理員 (EPM) 或 XLANG 的訊息數目上限。 這不包含從資料庫擷取但仍在等候記憶體內部佇列中傳遞的訊息。 您可以使用 BizTalk：Message Agent 效能物件類別下的進程內訊息計數效能計數器來監視進程內訊息的數目。 此參數提供提示給節流機制，做為節流狀況的考量。 實際閾值會受自我調整影響而不同。 您可以監控 [內含式訊息計數] 效能計數器，以確認實際閾值。
對於大型訊息案例 (其中平均訊息大小很高，或訊息處理可能需要大量訊息) ，此參數可以設定為較小的值。 指出大型訊息案例是否太常發生記憶體型節流，以及記憶體臨界值是否自動調整為大幅低的值。 此類行為發生時表示輸出傳輸應減少同時處理的訊息數，以避免過度使用記憶體。 此外，對於一次處理少量訊息可讓配接器較有效率的實例 (例如，傳送至限制並行連線的伺服器時)，此參數可調整為低於預設的值。 此分析會檢查非預設值的高 In-Process 訊息計數節流閾值。
參考資料
BizTalk 訊息代理程式處理記憶體使用量 (MB) 節流分析
這是目前進程 (MB) 的記憶體使用量。 如果要發佈的批次有尖峰的記憶體需求，或太多執行緒正在處理訊息，則會發生 BizTalk 進程記憶體節流。 如果系統似乎過度節流，請考慮增加與主機進程記憶體使用量閾值相關聯的值，並確認主機實例不會產生「記憶體不足」錯誤。 如果增加進程記憶體使用量閾值而引發「記憶體不足」錯誤，請考慮減少每個 CPU 閾值的內部訊息佇列大小和進程內訊息的值。 此策略特別會與大型訊息處理實例有關。
如果您的 BizTalk 伺服器定期用盡虛擬記憶體，請考慮BizTalk Server 64 位。 64 位伺服器上的每個進程最多可以處理 4 TB 的虛擬記憶體，以及 32 位中的 2 GB。 一般而言，強烈建議使用 64 位 BizTalk 和 64 位SQL Server。 See the “BizTalk Server 64-bit Support” reference for more information. 此分析會檢查進程記憶體使用量是否大於其相同名稱的個別節流臨界值 80%。 根據預設，BizTalk 進程記憶體使用量節流設定為進程可用的虛擬記憶體 25%。 /3GB 參數不會影響此設定。
參考資料
BizTalk：訊息代理程式處理記憶體使用量 (MB) 節流臨界值分析
這是目前進程記憶體使用量的目前閾值， (MB) 。 視此進程的實際可用記憶體數量及其記憶體耗用量模式而定，閾值可能會動態調整。 如果要發佈的批次有尖峰的記憶體需求，或太多執行緒正在處理訊息，則會發生 BizTalk 進程記憶體節流。 如果系統似乎過度節流，請考慮增加與主機進程記憶體使用量閾值相關聯的值，並確認主機實例不會產生「記憶體不足」錯誤。 如果增加進程記憶體使用量閾值而引發「記憶體不足」錯誤，請考慮減少每個 CPU 閾值的內部訊息佇列大小和進程內訊息的值。 此策略特別會與大型訊息處理實例有關。
如果您的 BizTalk 伺服器定期用盡虛擬記憶體，請考慮BizTalk Server 64 位。 64 位伺服器上的每個進程最多可以處理 4 TB 的虛擬記憶體，以及 32 位中的 2 GB。 一般而言，強烈建議使用 64 位 BizTalk 和 64 位SQL Server。 See the “BizTalk Server 64-bit Support” reference for more information. 此分析會檢查進程記憶體節流是否設定為非預設值。
參考資料
意見反應
即將登場：在 2024 年，我們將逐步淘汰 GitHub 問題作為內容的意見反應機制，並將它取代為新的意見反應系統。 如需詳細資訊，請參閱：https://aka.ms/ContentUserFeedback。
提交並檢視相關的意見反應