慢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文件接收

回答

相关问题