【问题标题】:Is restarting Biztalk host instance as a daily schedule job a best practice?将 Biztalk 主机实例作为每日计划作业重新启动是最佳做法吗?
【发布时间】:2012-08-13 04:03:10
【问题描述】:

我是 BizTalk 新手,最近遇到了 biztalk 编排卡住的问题,我不得不重新启动主机实例以再次处理消息。

我发现奇怪的是通过测试,我可以看到任务管理器中的 biztalk 主机实例占用了大量内存并且即使在编排进入脱水模式后也不释放它们。

是因为我在 biztalk 编排中进行了一些糟糕的编程吗?

仅供参考,我的业务流程使用一个实用程序 DLL,该 DLL 调用 WCF 从 SQL Server 2008 R2 检索数据。

编排使用计时器实用程序进行编程,以在四个小时不操作后退出。

设置:仅供参考,我在 windows server 2008 r2 中使用 biztalk 2009,24GB 内存,intel xeon 处理器。

更新:

你们是对的,正如预期的那样!

重新启动主机实例并不能真正解决这个问题,到目前为止我仍然不知道它有什么问题。

我已经进行了调试诊断运行以获取内存转储,我相信内存正在被 biztalk 应用程序的架构和其他部分消耗,所以我认为这可能没问题。

我确实偶然发现了 long list of cumulative updates 并试图查看我需要安装哪个来解决此问题。

谢谢!

【问题讨论】:

  • 除了部署新应用或对主机或适配器进行配置更改之外,没有理由重新启动实例(有许多 prod BTS 服务器在重新启动之前处理数百万条消息)。您的自定义程序集似乎有泄漏。
  • 这就是我害怕的,但至少你们帮我确认一下。谢谢
  • 您能否告知您从 SQL 查询中提取了多少数据?行和大小(即 Kb's / Mb's);另外,查询需要多长时间?

标签: biztalk biztalk-2009


【解决方案1】:

在 .Net 帮助程序代码中执行所有 Wcf 和 SQL 调用绝对是不是最佳做法,也不是定期重新启动主机实例。

有什么方法可以重构代码以使用开箱即用的适配器?如果做不到这一点,请尝试使用memory profiler 来查看内存泄漏的位置。

【讨论】:

  • 我同意这一点 - Biztalk 中的适配器设计得非常好,具有企业级质量
  • 将对其进行调查,因为它已经投入生产,如果可能的话,希望尽量减少任何重大变化。
  • wcf 设置起来有点棘手,但从发送端口调用它就可以正常工作。
【解决方案2】:

我认为 Biztalk 不需要每天重新启动。

我会确保您的 DLL 中的所有资源都得到适当的清理/处置。然后在测试中做一些测量,看看是不是你的代码给服务器带来了负载。

【讨论】:

  • 你是说我的 dll 占用了所有内存吗?有什么工具可以用来检查吗?谢谢
【解决方案3】:

您不应每天重新启动 BizTalk 主机实例,BizTalk 是一种企业产品,通常用于关键任务应用程序。

当你说很多内存是什么意思?默认情况下,BizTalk 主机实例进程内存消耗的限制设置为可用系统内存的 25%。因此,如果您的服务器有 32GB 内存,BizTalk 服务器将假定在应用任何限制条件之前达到 8GB 消耗是安全的。

您可以使用 Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) 深入挖掘 BizTalk 主机实例并查看您的内存消耗在哪里。以我的经验,它总是会产生一些自定义代码。查看您的自定义 DLL,看看他们是否使用 XmlDocument 之类的技术来加载大文档以解析某些值。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-09-27
    • 1970-01-01
    • 1970-01-01
    • 2019-02-17
    • 2014-05-30
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多