Fatal编程技术网
  • biztalk/
  • BizTalk文件接收速度慢

BizTalk文件接收速度慢

biztalk

BizTalk文件接收速度慢,biztalk,Biztalk,我有一个文件接收位置的应用程序。主机实例运行数小时后，接收位置无法识别放入其监视的文件夹中的新文件。它并没有完全忘记它们，只是性能令人毛骨悚然。接收位置配置为每60秒轮询一次目标文件夹，但在主机实例运行大约一小时后，似乎每30分钟才轮询一次目标文件夹。如果重新启动主机实例，则会立即收集目标文件夹中等待的文件，并且在接下来的一个小时左右性能良好 相同的应用程序在不同的环境中运行良好。 现在，事件日志中有与问题相关的明显条目。 除备份BizTalk Server（BizTalkMgmtDb）外，所有

我有一个文件接收位置的应用程序。主机实例运行数小时后，接收位置无法识别放入其监视的文件夹中的新文件。它并没有完全忘记它们，只是性能令人毛骨悚然。接收位置配置为每60秒轮询一次目标文件夹，但在主机实例运行大约一小时后，似乎每30分钟才轮询一次目标文件夹。如果重新启动主机实例，则会立即收集目标文件夹中等待的文件，并且在接下来的一个小时左右性能良好

相同的应用程序在不同的环境中运行良好。 现在，事件日志中有与问题相关的明显条目。 除备份BizTalk Server（BizTalkMgmtDb）外，所有BizTalk SQL作业都正常运行

感谢您的建议

谢谢

Rob

如果没有更多细节，最大的问题是你的备份工作失败了。如果备份作业失败，则可能未正确配置。如果它配置正确并且仍然失败，那么您还有其他问题。您能否提供有关BizTalk安装的更多信息

  • 你正在运行哪个版本
  • 我们的数据库大小是多少
  • 您的清除和归档设置是什么样的
  • SQL Server数据库中是否有来自BizTalk的长时间运行的块

    • 另一个要考虑的是发送、接收和编排主机正在运行的用户帐户。请检查BizTalk管理控制台。如果它们都运行同一个帐户，有时业务流程可能会耗尽发送和接收进程的CPU时间。我相信配乐优先，然后是接收，然后是发送。即使您只是在开发，使用单独的帐户也是很有用的。这也提高了安全性

    Wrox BizTalk Server 2006还将提供调整建议。

    该服务器还有哪些其他问题？BizTalk是以其他方式绑定的还是空闲的

    您提到解决方案在另一个环境中没有任何问题，因此可能存在配置问题

    检查以下各项：

    **在SQL Server上，为SQL Server设置一些内存上限。默认情况下，SQL Server使用它能得到的任何东西，然后挂起它，因此设置一个合理的限制，以便您的系统可以运行，而无需花费大量时间在硬盘上或从硬盘上分页内存

    **确保您有可用的磁盘空间—可能您的磁盘空间不足—这可能会导致各种奇怪的问题

    **尝试将系统的分页文件拆分为物理驱动器（如果系统上有多个驱动器）。也考虑使用一个更快的驱动器，或者如果你有大量的现金敷衍，得到一个SAN。 **在BizTalk中，是否启用了跟踪？如果是，您是否也在跟踪邮件正文？禁用固定或邮件正文跟踪，查看是否存在差异

    **运行解决方案时启动性能监视器并监视以下计数器

    • 对象：BizTalk消息传递
    • 实例：（选择接收主机）%%
    • 柜台：文件接收/秒

    • 对象：BizTalk消息传递

    • 实例：（选择发送主机）%%
    • 计数器：每秒发送的文件

    • 对象：XLANG/s业务流程

    • 实例：（选择处理主机）%%
    • 计数器：业务流程已完成/秒
    %%您可能只有一台主机，所以请使用它。由于BizTalk配置各不相同，因此我对主机使用通用名称

    前面的计数器监视服务器的最基本方面，但可能有助于缩小范围以进一步查看。当然，您也可以添加CPU和内存。如果您有时间（几天…也许几周），您可以监视分配内存的进程，而不会释放内存。使用以下计数器

    • 对象：内存
    • 计数器：池非分页字节
    此计数器缓慢下降表示进程没有释放内存，这会影响系统上的所有内容

    让我们知道事情的结果

    以下是一些其他工具，可以帮助您识别和诊断BizTalk数据库问题

    以下是修复已识别错误的工具：

    使用风险自负。。。阅读glogs和docs。从消息框查看器开始，让我们知道我们的结果。

    其他人的一些好建议。我将补充：

    在接收位置上是否有任何自定义接收管道组件？如果是这样的话，可能是内存泄漏，调用一些外部组件，例如数据库，这需要很长时间

    你收到的文件有多大

    在接收位置的文件传输属性上，将“文件重命名”设置为On，文件是否在60秒内重命名。

    我也有同样的问题，当我的业务流程闲置一段时间后，处理第一条消息花费了很长时间。EvYoung的一篇文章帮助我解决了这个问题

    “这是由BizTalk主机进程内的应用程序域卸载引起的。如果AppDomain在空闲后关闭，则出现的下一条消息需要等待业务流程再次编译。根据设计的复杂性，这可能是一个明显的等待。要在低延迟需求场景中防止这种情况，可以修改BTSNTSVC.EXE.config文件，并将SecondsIdleBeforeShutdown属性设置为-1。这将防止AppDomain因空闲而关闭。“

    你可以在这里找到这篇文章：

    我花了很长时间才做出回应，但我想我可能会帮助一些人。干杯：）

    这可能与网络有关吗？您是否通过UNC路径获取文件？嗨，克里斯，我们正在使用SQL Server 2005在一个两节点BizTalk组上运行BTS2006 enterprise。该组的BTS数据库