PAL（記錄效能分析）工具會讀取任何已知格式的性能監視器計數器記錄，並使用已知的複雜臨界值進行分析（提供）。 此工具會產生 HTML 型報告，以圖形方式繪製重要性能計數器的圖表，並在超過臨界值時擲回警示。 閾值最初是基於由 Microsoft 產品小組（包括 BizTalk Server）以及 Microsoft 支援部門成員所定義的閾值。 此工具不是取代傳統的效能分析，但它會將性能計數器記錄的分析自動化，以協助您節省時間。 PAL 工具：
分析性能計數器記錄以檢查臨界值
有助於處理大型效能監視器記錄
藉由分析閾值來識別 BizTalk Server 和作業系統的性能計數器瓶頸
可延伸以在任何性能計數器上進行分析
可用來協助編寫您自己的計數器程式
PAL 可在 GitHub 免費下載。 它需要 Microsoft 記錄剖析器。 記錄剖析器是功能強大的多功能工具，可提供文字型數據的通用查詢存取，例如記錄檔、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檔案，這是分析核心傾印根本原因所需的檔案。 |
| 磁碟：邏輯/實體磁碟介面分析 | 此分析會查看每個實體磁碟的空閒時間。 磁碟閑置越多，使用的磁碟就越少。 當在邏輯磁碟設定中只使用一個磁碟時，此計數器最為有效。 「% 閑置時間」會報告磁碟閑置樣本間隔期間的時間百分比。 參考： 排除 Disk-Bound 問題 |
| 磁碟：邏輯/實體磁碟讀取/寫入延遲分析 | Windows 偵測磁碟效能瓶頸的最可靠方式是測量其回應時間。 如果回應時間超過 0.025（25 毫秒），這是一個保守的閾值，那麼可能會出現影響使用者的明顯效能問題。 如需詳細資訊，請參閱本主題中的邏輯/實體磁碟讀取/寫入延遲分析。 |
| 磁碟：邏輯磁碟傳輸/秒 | 「磁碟傳輸/秒」是磁碟上的讀取和寫入作業速率。 此分析的臨界值會檢查是否有任何邏輯磁碟顯示回應時間不佳（I/O 作業的響應時間大於 25 毫秒）。 如果這是真的，則每秒的磁碟傳輸量應該在 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 和系統延遲增加。 如需詳細資訊，請參閱本主題中的 Available MemoryAnalysis。 |
| 記憶體：可用系統頁表條目 | 未使用系統分頁表項（PTE's）是目前系統未使用的頁表項目數量。 此分析透過檢查可用 PTE 是否少於 5,000 來判斷系統是否即將用完 PTE。如果可用 PTE 少於 10,000，則會發出警告。 缺乏足夠的 PTE 可能會導致全系統停止回應。 另請注意，/3GB 交換器會大幅降低可用 PTE 的數量。 如需詳細資訊，請參閱本主題中的可用系統頁表項分析。 |
| 記憶體：記憶體流失偵測 | 此分析會判斷任何進程是否耗用大量的系統記憶體，以及進程是否隨著時間在記憶體耗用量中增加。 只要進程將記憶體傳回系統，耗用大量記憶體的進程就沒問題。 試著找出圖表中數據增長的趨勢。 長時間的增長趨勢可能表示記憶體洩漏。 「私用位元組」是此進程已配置且無法與其他進程共用的記憶體目前大小，以位元組為單位。 此分析會檢查每小時 10 MB 和每小時 5 MB 的上升趨勢。 將此分析與 PAL 中的可用記憶體分析相互關聯。 如需詳細資訊，請參閱本主題中的記憶體流失偵測分析。 |
| 記憶體：處理流失偵測 | 此分析會檢查所有程序，以判斷每個程序已開啟多少個控制代碼，以及判斷控制代碼洩露是否可疑。 具有大量句柄和/或上升趨勢的進程可能表示句柄洩漏，這通常會導致記憶體洩漏。 此進程目前開啟的句柄總數等於此進程中每個線程目前開啟的句柄總和。 參考： 偵錯診斷工具 |
| 記憶體：記憶體分頁輸入速率/秒 | 「頁面輸入/秒」是從磁碟讀取頁面以解決硬式頁面錯誤的速率。 當進程參考虛擬記憶體中的頁面時，發生硬頁面錯誤，該頁面不在其工作集或實體記憶體的其他地方，而且必須從磁碟中擷取。 此分析會檢查每秒是否讀取超過10個頁面檔案。 |
| 記憶體：記憶體頁面/秒 | 此分析會檢查 「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 耗用量的函式。 |
| 處理器：處理器佇列長度 | 此分析會判斷平均處理器佇列長度是否超過處理器數目。 如果是，則這可能表示處理器瓶頸。 在 PAL 中，將此分析與特權模式 CPU 分析和進程過度使用處理器分析結合使用。 如需詳細資訊，請參閱本主題中的處理器佇列長度分析。 |
| 處理器：特權模式 CPU 分析 | 此計數器表示線程以特殊許可權模式執行的時間百分比。 當您的應用程式呼叫作系統函式時（例如執行檔案或網路 I/O 或配置記憶體），這些作系統函式會以特殊許可權模式執行。 此分析會檢查特殊許可權模式 CPU 是否耗用超過 30% 的總 CPU。 如果是，則 CPU 耗用量可能是由處理器以外的另一個瓶頸所造成，例如網路、記憶體或磁碟 I/O。 與處理器相互關聯：% 中斷時間和處理器：PAL 中的高內容切換分析。 如需詳細資訊，請參閱本主題中的特殊許可權模式 CPU 分析。 |
| 處理器：中斷時間 | 「% 中斷時間」是處理器在取樣間隔期間用於接收和處理硬體中斷的時間。 此值是產生中斷之裝置活動的間接指標，例如系統時鐘、滑鼠、磁碟驅動器、數據通訊線路、網路介面卡和其他周邊裝置。 這些裝置通常在完成任務或需要關注時，會中斷處理器的運作。 一般線程執行會在中斷期間暫停。 大部分的系統時鐘每隔 10 毫秒會中斷處理器，以建立中斷活動的背景。 此計數器的大幅增加表示潛在的硬體問題。 此分析會檢查「% 中斷時間」是否大於 30 百分比。 如果發生這種情況，請考慮更新與此警示相互關聯之硬體的裝置驅動程式。 參考： 使用 .NET Core 中的 EventCounters 測量效能 |
| 處理器：高頻率上下文切換 | 當較高優先順序的線程佔用目前執行的較低優先順序線程，或高優先順序線程封鎖時，就會發生內容切換。 當許多線程共用相同的優先順序層級時，可能會發生高層級的內容切換。 通常這表示過多的執行緒在系統上的處理器間競爭。 一般來說，若每個處理器的上下文切換率低於每秒 5,000 次，就不值得擔心。 如果內容切換速率超過每個處理器每秒 15,000 次，則會有限制。 如需詳細資訊，請參閱本主題中的高內容切換分析。 |
| Microsoft BizTalk Server：BizTalk 脫水協調流程 | 當許多長時間執行的商務程式同時執行時，可能會發生記憶體和效能問題。 協調流程引擎會藉由「解除凍結」和「重新凍結」協調流程實例來解決這些問題。 脫水是將工作流程的狀態串行化至 SQL Server 資料庫的過程。 解除凍結是此程式的反向：從資料庫還原串行化協調流程的最後一個執行狀態。 脫水過程是用來減少需在記憶體中同時具現化的協調流程數量，以最小化系統資源的使用。 因此，減損可節省記憶體耗用量，但執行作業成本相對較高。 此分析會檢查10個以上的脫水情況。 若是如此，BizTalk Server 可能會用盡記憶體（虛擬或實體）、大量協調流程正在等候訊息，或未正確設定凍結設定。 參考： 協調工作流程的脫水和復原 |
| Microsoft BizTalk Server：BizTalk 高資料庫會話 | 此計數器有兩個可能的值：一般 （0） 或超過 （1）。 此分析會檢查是否有值為 1 的。 如果是，BizTalk 已超過允許的資料庫會話數目閾值。 此值是由 BizTalk 主機節流設定中的「每個 CPU 的資料庫連線」值所控制。 「每個 CPU 的資料庫連線」是節流開始前允許的並行資料庫會話數目上限（每個 CPU）。 您可以使用 BizTalk：Message Agent 性能物件類別下的資料庫作業效能計數器來監視作用中資料庫連線的數目。 此參數只會影響輸出訊息節流。 如需詳細資訊，請參閱本主題中的BizTalk高資料庫會話分析。 |
| Microsoft BizTalk Server：BizTalk 資料庫大小過高 | 如果發生資料庫臨界值中訊息計數所列的任一條件，這個計數器將會設定為 1。 根據預設，資料庫節流閾值中的主機訊息計數會設定為 50,000，這會在下列情況下觸發節流條件： - 主機實例發佈至訂閱主機的工作、狀態和暫停佇列的訊息總數超過 50,000 個。 - 多任務緩衝處理數據表或追蹤數據表中的訊息數目超過 500,000 則訊息。 如果發生這種情況，請考慮一個可減少資料庫中訊息數目的動作。 例如，請確定 BizTalk Server 中的 SQL Server 作業執行時沒有發生錯誤，並使用 BizTalk Server 管理控制台中的 [群組中樞] 頁面來判斷訊息建置是否由大量暫停的訊息所造成。 如需詳細資訊，請參閱本主題中的BizTalk高資料庫大小分析。 |
| Microsoft BizTalk Server：BizTalk 高 In-Process 訊息數量 | 此分析會檢查高 In-Process 訊息計數計數器，以判斷是否發生這種節流。 如果是這樣，請考慮調整「CPU 每秒In-Process 訊息量」的設定。 此參數只會影響輸出訊息節流。 在 [每個 CPU 的In-Process 訊息] 設定中輸入值 0，以停用根據每个 CPU 處理中的訊息數目限制的流量控制。 「每個 CPUIn-Process 訊息」設定的預設值為 1,000。 請注意，修改此值也會對訊息和/或 BizTalk 資源的低延遲造成影響。 如需詳細資訊，請參閱本主題中的 BizTalk 高 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 的值，此設定也可以是 MB 的可用物理記憶體總數。 輸入 0 值，以根據物理記憶體使用量停用節流。 預設值為 0。 如需詳細資訊，請參閱本主題中的BizTalk高系統記憶體分析。 |
| Microsoft BizTalk Server：BizTalk 高線程計數 | 「每個 CPU 的線程」是主機進程中的線程總數，包括配接器所使用的線程。 如果超過此閾值，BizTalk Server 會嘗試減少 EPM 線程集區和訊息代理程式線程集區的大小。 在高負載可能導致建立大量線程的情況下，應該啟用線程型節流。 此參數會影響輸入和輸出節流。 執行緒型節流功能預設已停用。 如需詳細資訊，請參閱本主題中的BizTalk高線程計數分析。 |
| Microsoft BizTalk Server：BizTalk 主機佇列長度 | BizTalk 主機佇列長度會追蹤特定主機佇列中的訊息總數。 您可以使用長度大小，例如 BizTalk：MessageBox：HostCounters：Host Queue – Length，藉由顯示個別主機的佇列深度，更詳細地檢視內部佇列的訊息數目。 此計數器在判斷特定主機是否遇到瓶頸時很有用。 假設每個傳輸都使用唯一主機，這有助於判斷潛在的傳輸瓶頸。 此分析會檢查平均佇列長度是否大於 1。 主機佇列長度是一種經加權計算的佇列長度，方法是匯總目標主機所有佇列（工作佇列、狀態佇列、暫停佇列）的記錄數量。 參考： 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 訊息傳遞延遲 | 這是每個訊息傳遞批次的目前延遲毫秒（毫秒）（如果訊息傳遞受到節流處理則適用）。 至於節流，會根據訊息是輸入還是輸出，在發佈或處理訊息時套用延遲。 延遲期間會與節流條件的嚴重性成正比。 嚴重性較高的節流條件將導致更長的節流期間，相較於嚴重性較低的節流條件。 當條件變更時，節流機制會在特定範圍內上下調整此延遲期間。 目前的延遲期間會透過與 BizTalk：Message Agent 性能物件類別相關聯的性能計數器顯示，包括訊息傳遞延遲（ms）和訊息發佈延遲（ms）。 此分析會檢查訊息傳遞延遲大於 5 秒。 長時間的訊息傳遞延遲可能意味著由於負載過高而出現嚴重的頻寬限制。 參考： BizTalk Server 如何實作主機節流。 |
| BizTalk Server：BizTalk 訊息傳遞節流狀態 | BizTalk 訊息傳遞節流狀態是節流的主要指標之一。 這是一個旗標，指出系統是否正在節流訊息傳遞（影響 XLANG 訊息處理和輸出傳輸）。 節流條件是由計數器的數值表示。 如需詳細資訊，請參閱本主題中的 BizTalk 訊息傳遞節流狀態分析。 |
| BizTalk Server：BizTalk 訊息發佈延遲 | 在每個合格批次中注入的延遲，以限制訊息發佈的速度。 至於節流，會根據訊息是輸入還是輸出，在發佈或處理訊息時套用延遲。 延遲期間會與節流條件的嚴重性成正比。 嚴重性較高的節流條件將導致更長的節流期間，相較於嚴重性較低的節流條件。 當條件變更時，節流機制會在特定範圍內上下調整此延遲期間。 目前的延遲期間會透過與 BizTalk：Message Agent 性能物件類別相關聯的性能計數器顯示，包括訊息傳遞延遲（ms）和訊息發佈延遲（ms）。 此分析會檢測訊息發佈延遲超過 5 秒。 長時間的訊息傳遞延遲可能意味著由於負載過高而出現嚴重的頻寬限制。 參考： BizTalk Server 如何實作主機節流。 |
| BizTalk Server：BizTalk MessageBox 資料庫連線失敗 | 此性能計數器顯示，自主機實例啟動後，嘗試的資料庫連線失敗的次數。 如果因為任何原因而無法使用裝載 BizTalk 資料庫的 SQL Server 服務，資料庫叢集會將資源從主動電腦傳輸到被動計算機。 在此故障轉移過程中，BizTalk Server 服務實例會遇到資料庫連線失敗，並自動重新啟動以重新連線到資料庫。 運作中的資料庫電腦（先前是被動計算機）會在故障轉移期間假設資源之後開始處理資料庫連線。 如需詳細資訊，請參閱本主題中的 BizTalk MessageBox 資料庫連線失敗分析。 |
| BizTalk Server：BizTalk 傳訊延遲：要求回應延遲 | 傳訊引擎從配接器接收到要求文件，到回應文件回傳至配接器的時間，以毫秒為單位的平均延遲。 請參閱此主題中的圖表，該圖表顯示在 BizTalk 輸入延遲分析中如何計算延遲。 假設低延遲環境，此分析會檢查大於 5 秒的 Request-Response 延遲。 這可能表示輸入配接器與輸出配接器之間的處理延遲。 參考： - 要求/回應傳訊 - 調整您的解決方案 |
| 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 的Low-Latency 情境最佳化 |
| 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）輪詢表開始無限成長，或 2）每秒接收的訊息數目達到穩定，無論是哪一個情況先發生，即為您的最大永續輸送量。 總而言之，不論其他指標為何，此量值都會讓您快速且輕鬆地評估系統是否過度驅動。 當 BizTalk 寄送資料表的大小呈上升趨勢時，可能會因訊息傳遞速率不平衡（輸入速率超過輸出速率）或資料庫大小而發生節流。 此分析會檢查 BizTalk 多任務緩衝處理數據表大小的增加趨勢。 參考： - 瞭解 BizTalk Server 2004 SP1 輸送量和容量 - 永續性負載測試 - 測試引擎效能時的建議。 |
| BizTalk Server：BizTalk 追蹤數據大小 | 當 BizTalk Server 處理系統上越來越多的數據時，BizTalk 追蹤資料庫 （BizTalkDTADb） 會繼續成長大小。 未檢查的成長會降低系統效能，而且可能會在追蹤數據傳遞服務 （TDDS） 中產生錯誤。 除了一般追蹤數據之外，追蹤的訊息也可以在 MessageBox 資料庫中累積，導致磁碟效能不佳。 此分析會檢查追蹤數據大小是否有每小時增加超過 5 MB 的趨勢。 參考： 封存和清除 BizTalk 追蹤資料庫 |
| BizTalk Server：BizTalk 交易範圍中止 | 這是主機執行個體啟動以來被中止的長時間執行或原子性範圍的數目。 交易範圍中止操作是指在編排中的交易範圍內發生的失敗。 請務必瞭解，只有當作用域順利完成時，才會呼叫作用域的補償處理器，但如果周圍的作用域決定中止（因為流程稍後可能發生的故障），則需要進行復原。 此外，當交易中止時，不會發生狀態的「自動」復原。 您可以透過例外狀況和補償處理程式，以程式設計方式達成此結果。 交易範圍中止通常不應該發生在生產環境中;因此，此分析會檢查是否中止了任何交易範圍。 參考： 交易 |
| BizTalk Server：BizTalk 交易範圍已補償 | 補償可以被視為對已成功提交的工作進行邏輯上的還原，以回應錯誤狀況。 請務必瞭解，只有在範圍順利完成時，才會叫用範圍的補償處理程式，但必須復原，因為周圍範圍已決定中止（因為程式稍後可能發生的失敗）。 此外，當交易中止時，不會發生狀態的「自動」復原。 您可以透過例外狀況和補償處理程式，以程式設計方式達成此目的。 交易範疇的補償通常不應發生在生產環境中，因此，此分析會檢查是否存在任何被取消的交易範疇。 參考： 交易 |
| BizTalk Server：BizTalk 虛擬位元組 | 保留給主機實例的虛擬記憶體兆字節數。 此分析會判斷任何主機實例是否耗用大量的系統記憶體，以及主機實例是否隨著時間增加記憶體耗用量。 如需詳細資訊，請參閱本主題中的 BizTalk 虛擬位元組分析。 |
| BizTalk Server：BizTalk 訊息代理程式資料庫會話節流 | 這是 MessageBox 資料庫連線數目與其對應的 BizTalk 節流設定之間的比較。 「每個 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 如何實作主機節流 - 如何修改預設主機節流設定 - 影響配接器效能的組態參數 - 執行緒、資料庫連線和限流 |
| BizTalk Server：BizTalk 訊息代理程式線程計數節流閾值 | 這是進程中線程總數的目前臨界值。 「每個 CPU 的線程」是主機進程中的線程總數，包括配接器所使用的線程。 如果超過此臨界值，BizTalk Server 會嘗試減少 EPM 線程集區和訊息代理程式線程集區的大小。 在高負載可能導致建立大量線程的情況下，應該啟用線程型節流。 此參數會影響輸入和輸出節流。 此分析會檢查此節流設定是否設定為非預設值。 執行緒型節流功能預設已停用。 參考： - 主機節流性能計數器 - BizTalk Server 如何實作主機節流 - 如何修改預設主機節流設定 - 影響配接器效能的組態參數 - 線程、資料庫會話和節流控制 |
邏輯/實體磁碟讀取/寫入延遲分析
Windows 偵測磁碟效能瓶頸的最可靠方式是測量其回應時間。 如果回應時間超過 0.025（25 毫秒），這是一個保守的閾值，那麼可能會出現影響使用者的明顯效能問題。
磁碟延遲不佳的常見原因是磁碟分散、效能快取、過度飽和的SAN，以及磁碟上的負載過多。 使用 SPA 工具協助識別正在使用磁碟的檔案和程序。 另請檢查「處理 IO 資料作業/秒」和「處理 IO 其他作業/秒」，以查看哪些進程耗用最多的磁碟 I/O。 請記住，性能監視器計數器無法指定涉及哪些檔案。
參考資料
邏輯磁碟傳輸/秒
「磁碟傳輸/秒」是磁碟上的讀取和寫入作業速率。 雖然磁碟傳輸與磁碟 I/O 並不直接相關，但它確實能告訴我們正在進行多少磁碟作業。 如果您將循序 I/O 和隨機 I/O 進行平均，那麼通常的經驗法則表示每秒大約會有 80 次 I/O。 因此，當負載不足時，我們應該預期 SAN 磁碟驅動器每秒執行超過 80 個 I/O。 此分析的臨界值會檢查是否有任何邏輯磁碟顯示回應時間不佳（I/O 作業的響應時間大於 25 毫秒）。 如果這是真的，則我們應該預期每秒的磁碟傳輸在80以上。 如果沒有，則必須調查磁碟架構。 最常見的磁碟 I/O 問題是 SAN 上的邏輯單元編號（LUN）負載過重，這表示多個 LUN 使用小型實體磁碟陣列的情況。
可用的記憶體分析
“Available Mbytes” 是計算機上執行之進程可用的物理記憶體數量，以 MB 為單位。 Virtual Memory Manager 會持續調整實體記憶體和磁碟上所使用的空間，以維護作系統和進程最少可用的位元組數目。 當可用的位元組充足時，虛擬記憶體管理器可讓程序的工作集擴展，或者透過移除加入的每個新頁面來保持穩定。 當可用的位元組很少時，Virtual Memory Manager 必須修剪處理程式的工作集，才能維持所需的最小值。
此分析會檢查是否可用記憶體總量很低 – 可用10%時發出警告，5%時為危急狀態。 當偵測到每小時 10 MB 的下降趨勢時，也會發出警告，指出潛在的記憶體狀況。 低物理記憶體可能會導致特殊許可權模式 CPU 和系統延遲增加。
參考資料
記憶體流失偵測分析
此分析會判斷任何進程是否耗用大量的系統記憶體，以及進程是否隨著時間在記憶體耗用量中增加。 只要進程將記憶體傳回系統，耗用大量記憶體的進程就沒問題。 試著找出圖表中數據增長的趨勢。 長時間的增長趨勢可能表示記憶體洩漏。 私用位元組是此進程已配置且無法與其他進程共用的記憶體目前大小，以位元組為單位。 此分析會檢查每小時 10 MB 和每小時 5 MB 的上升趨勢。 將此分析與可用的記憶體分析相互關聯。
此外，請記住，當新啟動的進程看起來像是記憶體洩漏，但這只是正常的啟動行為。 當進程繼續耗用記憶體，且不會長時間釋放記憶體時，就會發生記憶體流失。
如果您懷疑記憶體流失狀況，請安裝並使用Debug Diag工具。 如需偵錯 Diag 工具的詳細資訊，請參閱參考一節。
參考文獻
記憶體頁面/秒分析
此分析會檢查 「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 瓶頸的函式>一文。
處理器佇列長度分析
「處理器佇列長度」是處理器佇列中的線程數目。 不同於磁碟計數器，此計數器只會顯示就緒的線程，而不是正在執行的線程。 即使在具有多個處理器的計算機上，處理器時間也有單一佇列。 因此，如果計算機有多個處理器，您必須將此值除以服務工作負載的處理器數目。 根據工作負載而定，每個處理器的持續處理器佇列通常可接受少於 10 個線程。
此分析會判斷平均處理器佇列長度是否超過處理器數目。 如果是，則這可能表示處理器瓶頸。 請將此分析與特權模式 CPU 分析及進程的過度處理器使用配合使用。 處理器佇列是已就緒但無法由處理器執行的線程集合，因為目前正在執行另一個作用中的線程。 超過處理器數目的線程持續或週期性佇列是處理器瓶頸的良好跡象。
您可以使用這個計數器搭配 「Processor\% Processor Time」 計數器來判斷您的應用程式是否可以受益於更多 CPU。 運算器時間有單一佇列，即使在多運算器電腦上也是如此。 因此，在多處理器計算機中，將「處理器佇列長度」（PQL） 值除以服務工作負載的處理器數目
如果 CPU 使用率非常高（90% 及更高），且 PQL 平均值恆高於處理器數量，那麼您可能會遇到處理器瓶頸，這種情況可以透過增加 CPU 來改善。 或者，您可以減少應用層級的線程和佇列數目。 這會導致較少的內容切換，這很適合降低CPU負載。 高處理器佇列長度（PQL）而 CPU 使用率偏低的常見原因是對處理器時間的要求隨機出現，且執行緒對處理器的時間需求不規則。 這表示處理器不是瓶頸。 相反地，你需要改善的是你的線程邏輯。
如果懷疑使用者模式處理器瓶頸，請考慮使用進程分析工具來分析造成高 CPU 耗用量的函式。 如需詳細資訊，請參閱參考一節中的<如何：識別導致伺服器應用程式在生產環境中造成高使用者模式 CPU 瓶頸的函式>一文。
特權模式 CPU 分析
此計數器表示線程以特殊許可權模式執行的時間百分比。 當您的應用程式呼叫作系統函式時（例如執行檔案或網路 I/O 或配置記憶體），這些作系統函式會以特殊許可權模式執行。
高優先權模式 CPU 表示電腦花費太多時間在系統 I/O，而不是在實際的使用者模式工作。 “% Privileged Time” 是進程線程花費在特殊許可權模式中執行程式代碼所耗用的時間百分比。 呼叫 Windows 系統服務時，服務通常會以特殊許可權模式執行，以取得系統私人數據的存取權。 在使用者模式中執行的線程會保護這類數據不受存取。 對系統的呼叫可以是明確或隱含的，例如頁面錯誤或中斷。 與某些早期作系統不同，除了傳統使用者和特殊許可權模式保護之外，Windows 也會使用子系統保護的程式界限。 除了進程的特殊時間之外，Windows 代表應用程式完成的部分工作可能會出現在其他子系統進程中。
此分析會檢查特殊許可權模式 CPU 是否耗用超過 30% 的總 CPU。 如果是，則 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 個。
訊息緩衝表或追蹤表中的訊息數量超過 500,000 則。
由於被暫停的訊息會包含在資料庫計算中的訊息計數中，即使 BizTalk 伺服器負載很低或沒有負載，仍可能會調節訊息發佈速度。
此分析會檢查是否有值為 1 的。 如果發生這種情況，請考慮一個可減少資料庫中訊息數目的動作。 例如，請確定 BizTalk SQL Server 作業執行時沒有發生錯誤，並使用 BizTalk 管理控制台中的群組中樞來判斷訊息建置是否由大量暫停的訊息所造成。
參考資料
BizTalk 高 In-Process 訊息計數分析
主機節流設定中的「每個 CPU 處理中訊息」設定是未處理的訊息數上限，這些訊息被傳送至端點管理員（EPM）或 XLANG。 此數位不包含從資料庫擷取的訊息，但仍在記憶體內部佇列中等待傳遞。 您可以使用 BizTalk：Message Agent 性能物件類別下的行程內訊息計數性能計數器來監視行程內訊息的數目。 考慮節流條件時，此參數可作為節流機制的提示。 實際的臨界值會自動調節。 您可以透過監控進程內訊息數的性能計數器來驗證實際閾值。
這個參數可以設定為較小的大型訊息案例值，其中平均訊息大小很高，或訊息的處理可能需要大量的訊息。 這是顯而易見的，若一個情境過於頻繁地經歷以記憶體為基礎的節流，並且記憶體臨界值會自動調整為非常低的數值。 這類行為表示輸出傳輸應該同時處理較少的訊息，以避免記憶體使用量過多。 此外，針對轉接器在一次處理一些訊息時更有效率的情況（例如，傳送至限制同時連線數量的伺服器時），此參數可以調整為低於預設值。
此分析會檢查高 In-Process 訊息計數計數器，以判斷是否發生這種節流。 如果是這樣，請考慮調整「CPU 每秒In-Process 訊息量」的設定。 此參數只會影響輸出訊息節流。 在 [每個 CPU 的In-Process 訊息] 設定中輸入值 0，以停用根據每个 CPU 處理中的訊息數目限制的流量控制。 「每個 CPUIn-Process 訊息」設定的預設值為 1,000。 請注意，修改此值也會對訊息和/或 BizTalk 資源的低延遲造成影響。
參考資料
BizTalk 高訊息傳遞率分析
對於輸出（已傳遞）訊息，如果主機實例的訊息傳遞速率超過訊息傳遞傳出速率 * 指定的速率超速因素 （百分比） 值，BizTalk Server 會節流傳遞訊息。 在 [訊息處理節流設定] 對話方塊中可以設定「速率超驅係數」的百分比參數。 輸出訊息的速率型節流主要是藉由在從記憶體內部佇列中移除訊息之前引入延遲，然後再將訊息傳遞至端點管理員 （EPM） 或協調流程引擎以進行處理來完成。 未執行其他額外動作來實現基於速率的輸出訊息節流。
輸出頻寬限制可能會導致訊息傳遞延遲，訊息可能會累積在記憶體佇列中，並導致取出佇列的線程遭到封鎖，直到節流狀況降低為止。 當封鎖佇列線程時，不會從 MessageBox 提取其他訊息到記憶體內部佇列以進行輸出傳遞。
此分析會檢查高訊息傳遞速率計數器是否有值為 1。 高訊息傳遞率可能是因為處理複雜度高、輸出配接器緩慢或系統資源暫時短缺所造成。
參考資料
BizTalk 高進程記憶體分析
如果輸入從 1 到 100 的值，BizTalk 進程記憶體使用量節流閾值設定是所使用的記憶體百分比，相較於工作集大小和進程可用虛擬記憶體總數的總和。 根據預設，BizTalk 進程記憶體使用量節流設定為 25。 指定百分比值時，進程記憶體閾值會定期重新計算。 如果使用者指定百分比值，則會根據可分配的記憶體和目前的程序記憶體使用量來計算。
此分析會檢查高程序記憶體計數器中是否有值為 1。 如果發生這種情況，請嘗試使用偵錯 Diag 來判斷記憶體增加的原因（請參閱記憶體流失偵測分析中的參考）。 請注意，進程在啟動期間取用大部分記憶體是正常的，這一點一開始可能會顯示為記憶體流失，但當進程無法釋放不再需要的記憶體時，就會發生真正的記憶體流失，進而減少一段時間的可用記憶體數量。 如需如何在 BizTalk 中一般分析進程記憶體流失的詳細資訊，請參閱下列「如何擷取記憶體流失的進程記憶體傾印」參考，和/或 PAL 中的「記憶體流失偵測」分析。
如果要發佈的批次有陡峭的記憶體需求，或太多線程正在處理訊息，則可能會發生高進程記憶體節流。 如果系統似乎過度節流，請考慮增加與主機進程記憶體使用量閾值相關聯的值，並確認主機實例不會產生「記憶體不足」錯誤。 如果因增加進程記憶體使用量的閾值而引發「記憶體不足」錯誤，請考慮減少內部訊息佇列大小和每個 CPU 的進程內訊息閾值的值。 此策略在大型訊息處理案例中特別相關。 此外，對於每個訊息有大型記憶體需求的情況，此值應設定為低值。 設定低值會使節流功能早期啟動，以防止程序中記憶體過度使用。
如果您的 BizTalk 伺服器定期用盡虛擬記憶體，請考慮 BizTalk Server 64 位。 64 位伺服器上的每個進程最多可以處理 4 TB 的虛擬記憶體，而 32 位中的 2 GB。 一般而言，強烈建議使用 64 位 BizTalk 和 64 位 SQL Server。 如需詳細資訊，請參閱
參考資料
BizTalk 高系統記憶體分析
如果輸入 1 到 100 的值，BizTalk 實體記憶體使用量節流閾值設定是相較於可用的實體記憶體總量的記憶體耗用百分比。 如果輸入大於 100 的值，此設定也可以是 MB 的可用物理記憶體總數。 輸入 0 值，以根據物理記憶體使用量停用節流。 預設值為 0。
此分析會檢查高系統記憶體計數器中的值 1。 因為這項措施測量的是系統記憶體總量，如果非 BizTalk Server 程序耗用大量的系統記憶體，可能會觸發節流條件。 因此，如果發生這種情況，最佳方法是識別哪些進程會耗用最多物理記憶體和/或將額外的物理記憶體新增至伺服器。 此外，請考慮減少 EPM 線程集區的預設大小，以及/或適配卡批次的大小來減少負載。 如需詳細資訊，請參閱 PAL 中的記憶體流失偵測分析。
參考資料
BizTalk 高線程計數分析
「每個 CPU 的線程」是主機進程中的線程總數，包括配接器所使用的線程。 如果超過此閾值，BizTalk Server 會嘗試減少 EPM 線程集區和訊息代理程式線程集區的大小。 在高負載可能導致建立大量線程的情況下，應該啟用線程型節流。 此參數會影響輸入和輸出節流。 執行緒型節流功能預設已停用。
備註
使用者指定的值會作為指導方針使用，而主機可能會根據進程的記憶體使用模式和線程需求，動態地自行調整此臨界值。
此分析會檢查「高線程計數」計數器中的值 1。 請考慮調整不同的線程集區大小，以確保系統不會建立大量的線程。 此分析可以與每秒的內容切換分析相互關聯，以判斷作業系統是否因太多的線程而飽和，但在大多數情況下，高線程計數會比在 BizTalk 伺服器上更容易引發後端資料庫的爭用。 如需修改線程集區大小的詳細資訊，請參閱如何修改參考中的預設主機節流設定。
參考資料
-
BizTalk 輸入延遲分析：從配接器接收文件到發布到訊息匣的平均延遲時間，單位為毫秒。 減少延遲對於 BizTalk 的某些使用者很重要，因此追蹤輸入配接器中文件花費的時間很重要。
以下圖表顯示測量延遲的方式。
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| 配接器會接收訊息，並將其提交至引擎。在將訊息提供給引擎之前，配接器內完成的工作不會在這些效能計數器中被擷取。 | 引擎從配接器接收訊息，執行接收管道、映射、訂閱評估，然後將訊息保存到資料庫中。 | 協作流程或 Solicit-Response 埠會執行並產生回應訊息。 | 回應訊息在傳訊引擎中出佇列，執行傳送管線和映射。 | 傳訊引擎會將回應消息提供給配接器。 | 配接器會通知引擎訊息已完成。 |
| 我 | |||||
| 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 orchestrations”相互關聯，其中問號（？）代表與此計數器相同的計數器實例。
如果大量的協調流程位於記憶體中，而且如果可解除凍結的協調流程數目不足，則您的協調流程可能會閑置在記憶體中，而且可能會導致記憶體流失狀況。 如果存在，請使用此分析與 “\XLANG/s Orchestrations\\Idle orchestrations” 相互關聯。 BizTalk 閑置協調流程中的上升趨勢是記憶體流失的較佳指標，因為無法解除凍結協調流程實例。
此分析會檢查駐在記憶體中的協調流程呈上升趨勢，以及記憶體中駐有的協調流程中是否有超過 50 個% 無法解除凍結。
參考資料
BizTalk 私用位元組分析
主機實例的已分配私人記憶體數量（以 MB 計）相當於“\Process(*)\Private Bytes” 性能計數器。 Private Bytes 是進程已配置且無法與其他進程共用之內存的目前大小，以位元組為單位。 此分析會判斷任何主機實例是否耗用大量系統的記憶體，以及主機實例是否隨著時間在記憶體耗用量中增加。 只要一個主機實例能夠將記憶體傳回至系統，使用大量記憶體是可以的。 試著找出圖表中數據增長的趨勢。 長時間的增長趨勢可能表示記憶體洩漏。
此分析會檢查每小時增加 10 MB 的趨勢。 使用此分析與可用的記憶體分析和記憶體流失分析相互關聯。 此外，請記住，剛啟動的主機實例可能會初步顯示為記憶體洩漏，但這只是正常的啟動行為。 記憶體流失是進程繼續耗用記憶體，而不會長時間釋放記憶體時。 如果您懷疑記憶體流失狀況，請閱讀下面所參考的「BizTalk 訊息中的記憶體成長」一文。 否則，請安裝並使用Debug Diag工具。 如需偵錯 Diag 工具的詳細資訊，請參閱參考一節。
參考資料
BizTalk 虛擬位元組分析
保留給主機實例的虛擬記憶體兆字節數。 此分析會判斷任何主機實例是否耗用大量的系統記憶體，以及主機實例是否隨著時間增加記憶體耗用量。 只要主機實例將記憶體歸還系統，即使耗用大量記憶體也是可以的。 試著找出圖表中數據增長的趨勢。 長時間的增長趨勢可能表示記憶體洩漏。
此分析會檢查虛擬位元組的趨勢，是否以每小時增加 10 MB 的速度。 使用此分析與可用的記憶體分析和記憶體流失分析相互關聯。 此外，請記住，剛啟動的主機實例一開始會在只是正常啟動行為時顯示為記憶體流失。 記憶體流失是進程繼續耗用記憶體，而不會長時間釋放記憶體時。 如果您懷疑記憶體流失狀況，請閱讀下方的
參考資料
BizTalk 訊息代理程式資料庫會話節流分析
這是 MessageBox 資料庫連線數目與其對應的 BizTalk 節流設定之間的比較。 「每個 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 性能物件類別下的行程內訊息計數性能計數器來監視行程內訊息數目。 此參數提供節流機制的提示，以考慮節流條件。 實際的臨界值會自動調節。 您可以藉由監視處理中訊息計數效能計數器來驗證實際門檻值。
對於大型訊息案例（其中平均訊息大小很高，或訊息處理可能需要大量的訊息），此參數可以設定為較小的值。 大型訊息案例會指出記憶體型節流經常發生，以及記憶體臨界值是否自動調整為低值。 這類行為表示輸出傳輸應該同時處理較少的訊息，以避免記憶體使用量過多。 此外，針對轉接器在一次處理一些訊息時更有效率的情況（例如，傳送至限制同時連線數量的伺服器時），此參數可以調整為低於預設值。 此分析會檢查 High In-Process Message Count 計數器，以判斷它是否超過相同名稱下其節流設定的 80%，這表示可能達到節流條件。
參考資料
BizTalk：訊息代理程式處理中訊息計數抑制閾值分析
這是服務類別正在處理的並行訊息數目目前的臨界值。 主機節流設定中的「每個 CPU 處理中訊息」設定是未處理的訊息數上限，這些訊息被傳送至端點管理員（EPM）或 XLANG。 這不包括從資料庫擷取的訊息，但仍在記憶體內部佇列中等待傳遞。 您可以使用 BizTalk：Message Agent 性能物件類別下的行程內訊息計數性能計數器來監視行程內訊息數目。 此參數提供節流機制的提示，以考慮節流條件。 實際的臨界值會自動調節。 您可以透過監控「In-process message count」效能計數器來驗證實際的臨界值。
對於大型訊息案例（其中平均訊息大小很高，或訊息處理可能需要大量的訊息），此參數可以設定為較小的值。 大型訊息案例會指出記憶體型節流經常發生，以及記憶體臨界值是否自動調整為低值。 這類行為表示輸出傳輸應該同時處理較少的訊息，以避免記憶體使用量過多。 此外，針對轉接器在一次處理一些訊息時更有效率的情況（例如，傳送至限制同時連線數量的伺服器時），此參數可以調整為低於預設值。 此分析會檢查非預設值的高 In-Process 訊息計數限制閾值。
參考資料
BizTalk 訊息代理程式處理記憶體使用量 （MB） 節流分析
這是目前進程的記憶體使用量（MB）。 如果要發佈的批次有陡峭的記憶體需求，或太多線程正在處理訊息，則 BizTalk 進程記憶體節流可能會發生。 如果系統似乎過度節流，請考慮增加與主機進程記憶體使用量閾值相關聯的值，並確認主機實例不會產生「記憶體不足」錯誤。 如果因提升進程記憶體使用閾值而引發「記憶體不足」錯誤，請考慮減少內部訊息佇列的大小以及每個 CPU 的進程內訊息閾值。 此策略在大型訊息處理案例中特別相關。
如果您的 BizTalk 伺服器定期用盡虛擬記憶體，請考慮 BizTalk Server 64 位。 64 位伺服器上的每個處理程序最多可以使用 4 TB 的虛擬記憶體，而在 32 位系統中，每個處理程序最多只能使用 2 GB 的虛擬記憶體。 一般而言，強烈建議使用 64 位 BizTalk 和 64 位 SQL Server。 如需詳細資訊，請參閱
參考資料
BizTalk：訊息代理程式處理記憶體使用量 （MB） 節流閾值分析
這是目前進程記憶體使用量的目前臨界值（MB）。 根據此進程的實際可用記憶體數量及其記憶體耗用量模式，可以動態調整臨界值。 如果要發佈的批次有陡峭的記憶體需求，或太多線程正在處理訊息，則 BizTalk 進程記憶體節流可能會發生。 如果系統似乎過度節流，請考慮增加與主機進程記憶體使用量閾值相關聯的值，並確認主機實例不會產生「記憶體不足」錯誤。 如果因增加進程記憶體使用量閾值而引發「記憶體不足」錯誤，請考慮減少內部訊息佇列大小和每個 CPU 的進程內訊息量的閾值。 此策略在大型訊息處理案例中特別相關。
如果您的 BizTalk 伺服器定期用盡虛擬記憶體，請考慮 BizTalk Server 64 位。 64 位元伺服器上的每個程序最多可以尋址 4 TB 的虛擬記憶體，相比於 32 位元的伺服器中只能尋址 2 GB。 一般而言，強烈建議使用 64 位 BizTalk 和 64 位 SQL Server。 如需詳細資訊，請參閱