BizTalk Orchestration如何清理已消费消息以释放内存？

核心结论：是的，绝大多数场景下的内存持续堆积都是Orchestration中留存的已消费消息导致的，你关闭消息跟踪仅能消除消息写入跟踪数据库的开销，不会影响运行时内存中的消息生命周期，因此无法缓解内存上涨问题。

• 消息作用域配置错误：如果单页拉取的REST响应消息、拆分映射后的内部消息都定义在Orchestration的根全局作用域，这些消息实例会一直持有到整个Orchestration实例完全结束才会被标记为可回收，循环过程中每一页的已消费消息都会持续堆积在内存中。
• 作用域补偿/恢复机制残留：如果你的循环逻辑放在开启了事务或补偿的作用域内，BizTalk会保留作用域内所有产生的消息副本用于故障回滚或补偿操作，哪怕单页已经处理完成，这些副本也不会被主动清理。
• 大对象堆(LOH)碎片化：如果你拆分单页数据时用了XMLDocument等非流处理方式加载整个消息体，超过85KB的对象会被分配到LOH，而BizTalk宿主进程默认GC触发阈值很高，频繁循环的情况下还没等GC运行，LOH碎片化就会导致内存无法被有效回收。
• 发送端口运行时缓存：即使关闭了跟踪，发送端口处理大消息时默认会在内存中留存消息缓存，处理完成后不会立即清空，循环处理大量单页数据时缓存会持续累积。

• 调整消息作用域范围：把单页全流程逻辑（REST接口调用、响应接收、数据拆分、映射、内部消息发送）封装到独立的嵌套作用域中，所有单页相关的消息、变量都定义在该嵌套作用域内部，作用域执行完成后，内部所有消息实例会立即被标记为可回收，无需等待整个Orchestration结束。
• 关闭不必要的作用域特性：将嵌套作用域的「事务类型」设为「无」，「补偿」选项设为「无」，BizTalk会在作用域执行完成后立即清理内部所有消息副本，无需保留用于故障恢复。
• 主动触发内存回收：在嵌套作用域的末尾添加表达式形状，写入代码System.GC.Collect(); System.GC.WaitForPendingFinalizers();，建议每处理5-10页调用一次，避免频繁调用带来的性能损耗。
• 改用流处理操作数据：避免用XMLDocument加载全量消息，改用XmlReader、VirtualStream等BizTalk原生流处理类操作数据，降低LOH的内存占用和碎片化概率。
• 调整宿主配置参数：在BizTalk管理控制台的宿主设置中，调低内存阈值触发值，让宿主节流机制更早触发GC清理；同时将「大消息阈值」调整为和单页消息大小接近的数值，让超过阈值的消息直接走磁盘缓存，不占用内存空间。

内容的提问来源于stack exchange，提问作者JERKER