共用方式為

BizTalk Server 層中的瓶頸

  • 發行項

BizTalk 層可以區分為下列功能區域：

  • 接收

  • 處理

  • 傳輸

  • 追蹤

  • 其他

    針對這些區域，如果系統資源 (CPU、記憶體和磁碟) 似乎飽和，請根據應用程式的特性相應增加或相應放大平臺來升級伺服器。 如果系統資源尚未飽和，請執行在此節中描述的步驟。

接收位置中的瓶頸

例如，如果訊息建置在接收位置 (，則檔案接收資料夾會成長大型) ，這表示系統無法快速吸收數據，以跟上傳入的負載。 這是因為內部節流。 也就是說，如果訂閱者無法快速處理數據，導致資料庫數據表中的待辦專案建置，BizTalk Server 減少接收率。 如果瓶頸是因為硬體限制所造成，請嘗試相應增加。 如需相應增加的詳細資訊，請參閱 BizTalk Server 2010 檔中的下列主題：

處理瓶頸

如果主機佇列 – 長度性能計數器正在增加，表示協調流程的速度不夠快。 如需詳細資訊，請參閱本主題中的 Perfmon 計數器數據表。 這可能是由於記憶體爭用或 CPU 飽和而導致。

如果協調流程伺服器是瓶頸所在，請使用 Perfmon 以識別來源。

如果伺服器受限於 CPU 處理能力，請考慮下列各項：

  • 如果工作流程很複雜，請考慮將協調流程分割成多個較小的協調流程

    注意

    將協調流程切割為多個工作流程，可能會導致額外的延遲狀況，並增加複雜度。 多個工作流程也可能會增加從 BizTalkMsgBoxDb 發佈和取用的訊息數目，對資料庫造成額外的壓力。

  • 如果您使用複雜的對應，請考慮是否可以將它們移至接收/傳送埠。 請務必確認哪些埠具有額外的頻寬。

  • 請考慮藉由設定額外的處理伺服器來相應增加硬體或相應放大。

傳輸瓶頸

如果裝載傳送配接器的伺服器在資源上飽和 (，例如磁碟、記憶體或 CPU) ，請考慮相應增加伺服器或向外延展至其他傳送主機伺服器。 如果目的地 (在 BizTalk 外部) 無法以夠快的速率接收資料，則傳送層可能會成為瓶頸。 這會導致訊息在 MessageBox 資料庫 (Application SendHostQ) 中累積。

如果所有端點都在拓撲的範圍內，請隔離目的地的原因。 例如，判斷 HTTP 位置是否已以最佳方式設定為接收負載。 如果沒有，請考慮相應放大。同時判斷目的地是否因為 BizTalk 傳遞的輸出訊息過多而成長。 如果是，您可能需要維護計劃來封存並清除目的地訊息。 目的地資料夾中的大量檔案可能會嚴重影響 BizTalk 服務將數據認可至磁碟驅動器的能力。

追蹤瓶頸

追蹤主機實例負責將 Business Activity Monitoring (BAM) 和 Health and Activity Tracking (HAT) 數據從 MessageBox 資料庫 (TrackingData 數據表) 移至 BizTalk 追蹤和/或 BAM 主要匯入資料庫數據表。 如果已設定多個 MessageBox 資料庫，追蹤主機實例會針對每個 MessageBox 資料庫使用四個線程。

追蹤主機實例可能是 CPU 系結。 如果是，請考慮藉由設定已啟用主機追蹤的額外伺服器來相應增加伺服器或相應放大。 已設定多個 MessageBox 資料庫的多個主機實例會自動進行負載平衡。 如需調整的詳細資訊，請參閱 調整解決方案 (https://go.microsoft.com/fwlink/?LinkId=158078) 主題。

如果 MessageBox 資料庫中的 TrackingData 數據表成長很大，通常是因為 BizTalk 追蹤和/或 BAM 主要匯入資料庫上的數據維護作業未如設定執行，導致 BizTalk 追蹤和/或 BAM 主要匯入資料庫的成長。 這些資料庫成長過大之後，可能會對追蹤主機將數據插入 TrackingData 數據表的能力產生負面影響。 這會導致追蹤的數據備份在 MessageBox 資料庫數據表中。 TrackingData 數據表的成長導致節流啟動。

您應該只啟用應用程式所需的最小追蹤，因為這樣會降低記錄的數據量，並降低追蹤瓶頸的風險。 如需停用協調流程和傳送/接收埠等個別項目的追蹤設定的相關信息，請參閱 如何停用追蹤 (https://go.microsoft.com/fwlink/?LinkId=160064) 。

其他

設定部署拓撲，使不同的功能可在專用的外掛式主控件執行個體中執行。 如此一來，每個主機實例 (取得自己的資源集，例如，在32位系統上，2GB虛擬記憶體位址空間、句柄、線程) 。 如果伺服器有足夠的 CPU 前端和記憶體來裝載多個主機實例，則可以設定為在同一部實體計算機上執行。 如果沒有，請考慮將功能移至專用伺服器來相應放大。 在多個伺服器上執行相同的功能，也可以提供具有高度可用性的組態。

BizTalk 系統性能計數器

Object 執行個體 計數器 監控目的
處理器 _Total % Processor Time 資源爭用
流程 BTSNTSvc 虛擬位元組 記憶體流失/膨脹
流程 BTSNTSvc 私用位元組 記憶體流失/膨脹
流程 BTSNTSvc 控制代碼計數 資源爭用
流程 BTSNTSvc 執行緒計數 資源爭用
Physical Disk _實例 % Idle Time 資源爭用
Physical Disk _實例 Average Disk Queue Length 資源爭用

CPU 爭用

如果處理器已飽和，您可以將接收與傳送和協調流程分開，以分散應用程式。 若要這樣做，請建立個別主機、將主機對應至特定功能 (接收/傳送/協調流程/追蹤) ，並將專用伺服器新增至這些個別主機。 協調流程功能通常需要大量CPU。 如果您設定系統，讓協調流程在個別的專用伺服器上執行，這有助於改善整體系統輸送量。

如果部署多個協調流程，您可以將它們編列到不同的專用協調流程主機。 將不同的實體伺服器對應至專用協調流程主機可確保不同的協調流程是隔離的，而且不會爭用相同實體位址空間或相同伺服器上的共享資源。

停止未使用的主機實例。 未使用的主機實例可以定期檢查 MessageBox 來處理訊息，以競爭 CPU 和記憶體資源。 此外，請停止未使用的接收位置、傳送埠和協調流程。

多任務緩衝處理數據表成長

下游瓶頸和/或資源爭用可能會導致多任務緩衝處理開始過度成長，並降低整體效能。 如需詳細資訊，請參閱 How to Identify Bottlenecks in the MessageBox Database1 中的。

記憶體耗盡

高輸送量實例可能增加對系統記體體的需求。 由於 32 位進程受限於可取用的記憶體數量，因此建議將接收/進程/傳送功能分成不同的主機實例，讓每個主機都會收到自己的 2GB 位址空間。 此外，如果多個主機實例在同一部實體伺服器上執行，您可以升級至 4/8GB 記憶體，以避免將數據從實際記憶體交換至磁碟。 長時間執行的協調流程可以保留較長的已配置記憶體。 這可能會導致記憶體流失和節流啟動。 大型訊息也可能造成高記憶體耗用量。

您可以降低特定主機每個CPU值的內部訊息佇列大小和進程訊息，以簡化大型訊息處理時所發生的記憶體不足問題。

注意

如果延遲是個問題，則應該謹慎處理每個CPU 的內部消息佇列大小 和 同進程訊息 的變更，因為這可能會增加系統的端對端延遲。

磁碟爭用

例如，如果磁碟已飽和 (，具有大量的 FILE/MSMQ 傳輸) ，請考慮升級至多個軸，並使用 RAID 10 等量磁碟。 此外，每當使用 FILE 傳輸時，請務必確保接收和傳送資料夾不會成長超過 50,000 個檔案。

如果 BizTalk Server 將傳入數據節流至系統，接收資料夾可能會成長很大。 請務必從傳送資料夾行動資料，讓此資料夾中的成長不會影響 BizTalk Server 寫入其他數據的能力。 對於非交易式 MSMQ 佇列，建議從遠端建立接收佇列，以便在 BizTalk Server 上減少磁碟爭用。

遠端非交易式佇列組態也會提供高可用性，因為裝載佇列的遠端伺服器可以叢集化。

其他系統資源爭用

視傳輸類型而定，可能需要設定 IIS 等系統資源，例如 HTTP (，例如 MaxIOThreads、MaxWorkerThreads) 。

在 ASP.NET 2.0 和 ASP.Net 4 中， <machine.config 檔案中的 processModel autoConfig=“true”> 設定會自動設定下列設定，以獲得最佳效能：

  • 背景工作線程上限

  • IO 線程上限

  • HTTPRuntime 元素的 minFreeThreads 屬性

  • HTTPRuntime 元素的 minLocalRequestFreeThreads 屬性

  • connectionManagement> 元素的 <maxConnection 屬性， (網路設定) 元素

    如需設定影響配接器效能的參數詳細資訊，請參閱 processModel 元素 (https://go.microsoft.com/fwlink/?LinkId=158080) ASP.NET 組態設定。

    如需可能會影響 BizTalk Server 配接器之組態設定的詳細資訊，請參閱影響配接器效能的組態參數 (https://go.microsoft.com/fwlink/?LinkID=154200) 。

    除了優化 BizTalk Server 應用程式之外，在相同伺服器上執行的其他 ASP.NET 應用程式可能會影響整體效能。 請務必將所有 ASP.NET 應用程式優化，以減少系統資源的需求。 如需詳細資訊，請參閱 ASP.NET 效能 (https://go.microsoft.com/fwlink/?LinkId=158081) 。

    設定最大效能時，請考慮優化其他外部系統，例如訊息佇列、MQSeries () 、應用程式、資料庫、Active Directory 等屬於整體 BizTalk 解決方案的一部分。 這些其他任何外部系統中的效能瓶頸對您的 BizTalk 解決方案可能會造成負面影響。

下游瓶頸

如果下游系統無法從 BizTalk 快速接收數據，此輸出數據將會備份在 BizTalk 資料庫中。 這會導致高載、導致節流啟動、壓縮接收管道，並影響 BizTalk 系統的整體輸送量。 這是 Spool 數據表成長的直接指示。 如需瓶頸和多任務緩衝處理數據表的詳細資訊，請參閱 How to Identify Bottlenecks in the MessageBox Database1。

節流影響

節流最終會開始保護系統，避免達到無法復原的狀態。 因此，您可以使用節流來驗證系統是否正常運作，並探索問題的來源。 找出節流狀態瓶頸的原因之後，請分析其他性能計數器來判斷問題的來源。 例如，MessageBox 資料庫上的高爭用可能是因為 CPU 使用率偏高所造成，因為過度分頁至記憶體不足狀況所造成的磁碟。 MessageBox 資料庫上的高爭用也可能是因為磁碟驅動器飽和而造成高鎖定競爭所造成。 雖然偶爾節流不是效能的重大威脅，但持續性節流可能表示更顯著的基礎問題。 如需 BizTalk Server 將使用節流之條件的詳細資訊，請參閱如何 BizTalk Server 實作主機節流https://go.microsoft.com/fwlink/?LinkID=155286 () 。

如需 BizTalk Server 節流如何協助管理可用資源的使用方式，並將資源爭用降至最低的詳細資訊，請參閱透過主機節流優化資源使用量 (https://go.microsoft.com/fwlink/?LinkID=155770) 。

BizTalk 應用程式計數器

Object 執行個體 計數器 描述
BizTalk 傳訊 RxHost 每秒接收文件數 內送速率
BizTalk 傳訊 TxHost 每秒處理文件數 外寄速率
XLANG/s 協調流程 PxHost 每秒完成的協調流程數 處理速度
BizTalk：MessageBox：一般計數器 MsgBoxName 多工緩衝處理大小 所有主控件佇列總計大小
BizTalk：MessageBox：一般計數器 MsgBoxName 追蹤資料大小 MessageBox 上的 TrackingData 資料表大小
BizTalk：MessageBox：主控件計數器 PxHost:MsgBoxName 主控件佇列 - 長度 指定主控件佇列中的訊息數
BizTalk：MessageBox：主控件計數器 TxHost:MsgBoxName 主控件佇列 - 長度 指定主控件佇列中的訊息數
BizTalk：訊息代理程式 RxHost 資料庫大小 發佈 (PxHost) 佇列的大小
BizTalk：訊息代理程式 PxHost 資料庫大小 發佈 (TxHost) 佇列的大小
BizTalk：訊息代理程式 HostName 訊息傳遞節流狀態 影響 XLANG 和輸出傳輸
BizTalk：訊息代理程式 HostName 訊息發佈節流狀態 影響 XLANG 和輸入傳輸

我該從哪裡開始？

監視 訊息傳遞節流狀態 ，以及每個主機實例的 訊息發佈節流狀態 是很好的起點。 如果這些計數器的值不是零，這表示 BizTalk 系統中的節流，您可以進一步分析瓶頸的原因。 如需其他性能計數器的描述，請參閱 資料庫層中的瓶頸。

協調流程引擎性能計數器

強烈建議您微調協調流程運行時間設定，因為持續協調流程解除凍結\解除凍結和持續性點可能會對整體效能造成嚴重影響。 測試可能包含多個持續性點和交易範圍的複雜協調流程時，您必須使用下列計數器。

計數器 註解
凍結的協調流程數/秒 平均每秒凍結的數目。
解除凍結的協調流程數/秒 平均每秒解除凍結的數目。
持續點數/秒 平均每秒保存的協調流程執行個體數。
記憶體中駐留的協調流程數 目前由主控件執行個體裝載的協調流程執行個體數。
完成的協調流程數/秒 平均每秒完成的數目。
擱置的協調流程數/秒 平均每秒擱置的數目。
認可的交易式範圍數/秒 平均每秒認可的數目。
中止的交易式範圍數/秒 平均每秒中止的數目。
補償的交易式範圍數/秒 平均每秒補償的數目。

待辦專案建置

如果是 1-1 個部署案例，其中收到 1 則訊息會導致處理並傳輸 1 則傳出速率不等於傳入速率，系統中會有待辦專案。 在此情況下，您可以監視多任務緩衝處理大小。 判斷傳出速率瓶頸的原因時，一次執行單一使用案例。 隔離協調流程、接收位置，以及將位置傳送至不同的主機。

將 BizTalk：Message Box：Host Counters 新增至您的 效能監視器 記錄檔，以監視主機。 主機佇列 - 長度：計數器會追蹤特定主機佇列中的訊息總數。 如果其中一或多個計數器持續成長一段時間，請特別注意這些主機所執行的成品。

如果多任務緩衝處理以線性方式成長，請判斷哪個應用程式佇列負責多任務緩衝處理成長。

如果沒有任何應用程式佇列成長，且多任務緩衝處理會繼續成長，這可能表示清除作業無法保持運作。 如果代理程式未執行，或 SQL Server 上有其他系統資源爭用，就會發生這種情況。

如果其中一個應用程式佇列成長，請診斷此成長的原因。 例如，監視系統上無法清空特定應用程式佇列的系統資源 (，協調流程主機 Q 因為伺服器上的 CPU 不足而成長) 。 此外，請確認特定主機實例的節流計數器值。

如果 BizTalk：Message Agent 訊息傳遞節流狀態和訊息發佈節流狀態性能計數器不是零，請檢查值以確認節流 (的原因，例如超過記憶體閾值、傳輸中的訊息計數太高等等) 。

Stand-Alone Profiler

您可以使用性能計數器來偵測高階瓶頸的位置。 不過，縮小后，您可能需要更仔細地檢查程式代碼，以協助減輕問題。 隨附於Visual Studio 2010的 Stand-Alone Profiler是一項非常實用的工具，可協助診斷程式代碼花費大部分週期的位置。 如需相關資訊，請參閱

L2/L3 快取

從硬體的觀點來看，您可以使用上線CPU快取來獲得最大的優點。 較高的 CPU 快取有助於增加快取命中率，減少系統從記憶體對磁碟進行來回資料分頁的需求。

64 位效能瓶頸

64 位元系統上的效能可能看來會低於在 32 位元系統上所能達到的效能。 這是可能的原因之一，其中最重要的一個是記憶體。

使用 2 GB 記憶體測量 32 位系統上的效能，並將結果與具有 2 GB 記憶體的類似 64 位系統進行比較，並不會比較相同的專案。 64 位系統看起來會是磁碟 I/O 系結 (低 % 磁碟閒置時間，& 高磁碟佇列長度) 和 CPU 系結 (最大 CPU 和高內容切換) 。 不過，這不是因為在64位系統上執行檔案 I/O 會比較昂貴。

64 位系統耗用大量記憶體， (64 位尋址) ，這會導致操作系統耗用大部分的 2 GB 可用記憶體。 發生這種情況時，大部分的其他作業都會造成分頁至磁碟，而使檔案子系統無法運作。 因此，系統會花費 CPU 週期來回分頁數據與程式代碼，並受到高磁碟延遲成本的影響。 這會造成系統呈現較高磁碟爭用和較高 CPU 耗用的情況。

減輕此問題的方式是藉由升級記憶體來相應增加伺服器。 不過，增加最多 8 GB 的概念是，除非問題的來源是 CPU 耗盡，因為記憶體不足，否則新增更多記憶體並不有助於改善輸送量。

使用 BAM 來識別瓶頸和高延遲問題

當低延遲很重要時，您可以使用 BAM 來測量系統完成 BizTalk Server 系統內每個階段所需的時間。 雖然您可以使用 HAT 來偵錯訊息的狀態，並診斷路由訊息中問題的來源，但您可以使用 BAM 透過訊息流程追蹤各種點。 藉由建立 BAM 追蹤設定檔來定義具有接續的活動，您可以測量系統不同部分之間的延遲，以協助追蹤工作流程程式內成本最高的階段。

您可以使用 HAT 中的協調流程調試程式來查詢暫停的實例、以偵錯模式繼續實例，以及使用技術詳細數據檢視新增適當的斷點。 這會讓您追蹤活動並逐步偵錯訊息。

您可以設定中斷點追蹤下列事件：

  • 協調流程的開始和結束

  • 圖形的開始和結束

  • 訊息的傳送或接收

  • 例外狀況

    在每個中斷點，您可以檢查有關區域變數、訊息及其屬性、連接埠和角色連結的資訊。

另請參閱

尋找並排除瓶頸