我们有一个BizTalk 2010接收位置，它将获得一个70MB的文件，然后使用入站映射（在接收位置）和出站映射（位于发送端口）生成一个1GB的文件。
在执行上述过程时，SQL Server中消耗了大量磁盘I/O资源。另一个接收位置进程的性能受到很大影响。
我们已经尝试减少该接收位置的主机实例中的最大磁盘I/O线程数，但它仍然会消耗SQL Server中的大量磁盘I/O资源。
事实上，这个过程的优先级非常低。是否有任何方法可以减少此进程的磁盘I/O资源使用量，以使其他进程的性能正常？
这个问题与文件输入的速度无关，但正如您在评论中提到的，当试图将1gb映射输出持久化到messagebox时，它会在messagebox上加载。这里有几个选项可以尽量减少对其他流程的影响：
- 将新创建的主机上的限制设置调整到非常低的值。这可能会也可能不会按照你想要的方式工作
- 在这些文件的接收位置设置一个服务窗口，以便它们只在非工作时间运行。如果你对MessageBox没有全天候的需求，并且可以承受半夜（比如凌晨2点至3点）的缓慢响应时间，那么这将是理想的选择
- 如果您的需求能够处理此问题，请不要在接收端口中映射文件，而是将其路由到编排和/或自定义管道组件，该组件将其拆分为较小的部分，然后映射较小的部分。这至少可以让您对处理这些片段的速度进行更细粒度的控制（在处理片段的循环中具有延迟形状）。当你把它们重新组合在一起时，仍然可能会有问题，但这应该不会像你目前的过程那么糟糕
这也可能值得一看你的地图。如果有很多缓慢/处理器繁重的调用，您可能可以对其进行重构。
理想情况下，您应该讨论该文件。将包括映射在内的业务逻辑应用于每个单独的分段，然后一次一个地将它们加载到sql中。稍后，您可以使用管道或其他.NET组件从SQL中提取数据并重新对数据进行批处理。在BizTalk消息框中处理大xml（与平面文件相比大小为10倍）不是一个很好的做法。然而，如果这是一个纯消息传递场景，您可以将文件转换为流并将其路由到目的地。