慢BizTalk文件接收

我有一個文件接收位置的應用程序。主機實例運行幾個小時後，接收位置無法識別放入正在監視的文件夾中的新文件。它並沒有完全忘記它們，它只是表現在慢慢爬行。接收位置被配置爲每隔60秒輪詢一次目標文件夾，但在主機實例運行了一個小時左右後，似乎目標文件夾每三十分鐘才輪詢一次。如果我重新啓動主機實例，那麼目標文件夾中等待的文件將立即收集起來，並且在接下來的一小時左右性能會很好。慢BizTalk文件接收

相同的應用程序在不同的環境中運行良好。現在在與問題相關的事件日誌中有明顯的條目。除備份BizTalk Server（BizTalkMgmtDb）外，所有BizTalk SQL作業均正常運行。

任何建議感激地收到。

感謝

羅布

來源

2009-05-19 Rob Bowman

它可以是網絡相關？你是通過UNC路徑獲取文件嗎？ – Riri 2009-05-19 18:11:10

這裏有一些額外的工具可以幫助您識別和診斷BizTalk數據庫問題。

BizTalk MsgBox Viewer

這裏是修復識別的錯誤的工具：

Terminator

使用您自己的風險...閱讀glogs和文檔。從消息框查看器開始，讓我們知道我們的結果。

來源

2009-05-26 18:12:32

我不認爲這個問題與msgbox有關。 BizTalk SQL服務器的全面健康檢查顯示沒有問題。雖然我們的應用程序在不同環境下運行正常，但我們遇到問題的環境是唯一經受負載測試的環境，也是唯一一個可以從此特定NAS盒子接收到的麻煩接收位置的地方 – 2009-05-28 14:42:32

如果沒有更多的細節，最大的講的是你的備份作業失敗。如果備份作業失敗，則可能無法正確配置。如果配置正確並且仍然失敗，那麼您還有其他問題。你可以給我們一些關於你的BizTalk安裝的更多信息。

你正在運行什麼版本？
我們的數據庫大小是多少？
什麼是你的清除和存檔設置？
您的SQL Server數據庫中是否存在來自BizTalk的長時間運行塊？

來源

2009-05-19 18:40:16

嗨Chris，我們在帶有SQL Server 2005的雙節點BizTalk羣組上運行BTS2006企業。羣組的BTS數據庫安裝在不同的服務器上。所有的服務器都是高規格的，BTS盒是四核CPU，42GB內存，SQL盒是8cpu和84gb Ram。 BTS和SQL框都幾乎空閒。所有BizTalk作業現在都已配置並運行，沒有問題。跟蹤db目前是9GB數據，1GB事務日誌。 MsgBox db目前是4GB數據，4GB事務日誌。沒有長時間運行的模塊 – 2009-05-28 14:37:11

要考慮的另一件事是發送，接收和編排主機正在運行的用戶帳戶。請檢查BizTalk管理控制檯。如果它們都運行相同的帳戶，有時編排可能會導致CPU時間的發送和接收過程中斷。我相信優先考慮的是接收後的協調，然後發送。即使您正在開發，爲此使用單獨的帳戶也很有用。這也提高了安全性。

Wrox BizTalk Server 2006也將提供優化建議。

來源

2009-05-20 21:48:51 QSmienk

我們有單獨的主機實例用於接收，編排和發送。雖然每個這些使用相同的域帳戶，我不認爲這會導致問題？ – 2009-05-28 14:39:27

服務器還有哪些其他的事情？ BizTalk是否掛鉤或閒置？

來源

2009-05-21 15:14:06 yieldvs

這是空閒的 – 2009-05-28 14:37:33

您提到該解決方案在其他環境中沒有任何問題，因此可能存在配置問題。

檢查以下內容：

**在SQL Server中，設置SQL服務器上的一些內存限制。默認情況下，SQL Server使用任何它可以獲得的東西，然後掛在它上面，所以設置一個合理的限制，這樣你的系統就可以在沒有很多時間將內存分頁到硬盤上的情況下運行。

**請確保您有可用的磁盤空間 - 可能您的磁盤空間不足 - 這可能導致各種各樣的奇怪問題。

**嘗試在其物理驅動器中分割系統的分頁文件（如果系統上有多個驅動器）。另外考慮使用更快的驅動器，或者如果你有大量的現金鋪設，獲得一個SAN。

**在BizTalk中，跟蹤是否啓用？如果是這樣，你是否也跟蹤郵件正文？禁止添加或消息正文跟蹤並查看是否有差異。

**啓動性能監視器，並監視下列計數器運行解決方案時

對象：BizTalk消息
Instance：（選擇接收主機）%%
計數器：文件接收/秒
對象：BizTalk消息
實例：（選擇T ransmitting主機）%%
計數器：文檔發送/秒
對象：XLANG/s業務
實例：（選擇處理主機）%%
計數器：業務流程完成/秒。

%%你可能只有一個主機，所以就使用它。由於BizTalk配置各不相同，因此我使用主機的通用名稱。

前面的計數器監視您的服務器的最基本的方面，但可能有助於縮小位置以進一步查看。當然，您也可以添加CPU和內存。如果你有時間（幾天或許幾周），你可以監視分配內存的進程並且永遠不會釋放它。使用下面的櫃檯......

對象：內存
計數器：池非分字節

此計數器的緩慢下降表明過程不釋放內存，從而影響系統上的一切。

讓我們知道結果如何！

來源

2009-05-21 21:27:40

其他一些很好的建議。我將補充：

您是否在接收位置有任何自定義接收管道組件？如果是這樣的話，也許是一個正在泄漏內存，調用一些外部組件，例如需要很長時間的數據庫？

您收到的文件有多大？

在接收位置的文件傳輸屬性上，設置「文件重命名」，在60秒內完成文件重命名。

來源

2009-06-08 10:20:16 foolshat

我有同樣的問題，當我的編排閒置了一段時間，它花了很長時間來處理第一個味精。 EvYoung的一篇文章幫助我解決了這個問題。

「這是由BizTalk主機進程中的應用程序域卸載引起的。如果AppDomain在空閒後關閉，則下一條消息需要等待Orchestration再次編譯。根據設計的複雜程度，可以是一個明顯的等待，爲了防止在低延遲需求情況下出現這種情況，可以修改BTSNTSVC.EXE.config文件並將SecondsIdleBeforeShutdown屬性設置爲-1，這樣可以防止AppDomain由於空閒而關閉。

您可以在文章中的位置： http://blogs.msdn.com/b/biztalkcpr/archive/2008/05/08/thoughts-on-orchestration-performance.aspx

我花了好長迴應，但我想我可能幫助別人。歡呼:)

來源

2012-01-30 13:54:16

慢BizTalk文件接收

回答

相關問題