我們的Biztalk 2006應用程序包含兩個頻繁調用的編排（每秒約15個請求）。我們通過在主機中執行某些限制閾值更改來識別可能的內存泄漏。當我們禁止基於內存的調節時，進程內存開始增加，直到1400 MB，之後我們開始體驗到內存不足異常。
當這種情況發生時，我們被迫重啓主機實例。
我們想知道在這種情況下顯式調用Orchestration中的GC.Collect是否富有成效。使用這種方法有什麼缺點？Biztalk中的垃圾收集，明智的做法是什麼？
謝謝。
不知道我的Biztalk的答案可能是遙遠......
我假設，在一個進程中運行更多的業務流程實例增加它採取單一的業務流程實例完成的時間。然後，當您增加同時運行的編排實例的數量時，在某個時間點，它們完成所需的時間將足夠大，以致正在運行的編排實例的大小對於您的RAM來說非常適合。
我認爲你需要根據正在運行的業務流程實例的數量進行限制。如果您將「完成率」與「正在運行的業務流程實例的數量」進行比較，您可能會在圖表中間看到一個很大的平坦區域，選擇您的節流將您置於穩定區域的中間。
僅當垃圾回收器無法釋放足夠的內存以執行請求的分配時，纔會發生內存不足異常。如果你有一個內存泄漏，在垃圾收集平臺中，這意味着某些對象引用會比他們需要的時間長。頻繁的泄漏原因是持有全局數據（靜態變量）的對象，例如單引號，緩存或池，導致引用時間過長。
如果您顯式調用GC.Collect，由於與隱式收集失敗相同的原因，它也將無法釋放內存。所以explit GC.Collect調用只會導致編制速度變慢。
如果要調用從您的業務流程的.NET類，我建議嘗試通過從一個純粹的.NET應用程序調用同一個類（不涉及的BizTalk）
也有可能，有沒有泄漏到隔離問題，但是每個實例在同一時間消耗太多內存。當BizTalk發現必要時，通常可以對業務流程進行脫水，但如果編排中的步驟（或大型原子範圍）執行時間太長，可能會阻止它。
1400mb同樣只有15個併發實例看起來很大。你是否在操作編排中的大消息？在這種情況下，您可以通過避免強制將整個消息加載到內存中的操作，而是使用流操作消息來大大減少內存使用量。
我同意上面的海報。嘗試清除內存或重置主機實例不是解決方案，而只是一個樂隊幫助。你需要找到你正在泄漏的內存。我會看整個應用程序，而不僅僅是編排;端口也可能導致內存泄漏。你在地圖中使用自定義的functoid嗎？內聯代碼如何？自定義xslt？ 如果您正在使用它們，我還會查看自定義管道。 如果可能我會嘗試隔離不同的組件，並將它們分別置於壓力和體積測試之下;不知何故，我不認爲你的編排本身就是問題，而是一個地圖或一個自定義組件。
做垃圾收集不會釋放內存泄漏，因爲它仍然（錯誤）以某種方式由您的應用程序引用。如果您做了大量生成短期對象並且知道您處於釋放它們的好時刻，則只能調用GC.Collect。
您必須識別並修復泄漏代碼！
我完全同意對方說的大部分 - 你應該看看你的漏洞在哪裏並修復它;直接調用GC不會對你有所幫助，無論如何都不太可能是一個合理的前進方向。
我想補充一句，如果你遇到資源消耗的突然增加，那麼節流的存在是爲了保護你的環境不被磨碎到停頓;沒有限制它是可能的BizTalk（像任何其他服務器）到達一個點，它不能繼續處理，並有效地「卡住」;爲了確保處理仍在進行，節流允許它減速，直到資源消耗水平（希望）恢復到正常水平;
因爲這個原因，我也建議你考慮爲你的環境配置一些限制，這些限制值必須調整以適合你的場景