BizTalk 服务器问题

Posted 2023-02-15

【中文标题】BizTalk 服务器问题

【英文标题】：BizTalk server problem

【发布时间】：2010-12-25 04:56:04

【问题描述】：

我们公司有一个 biztalk 服务器（一个虚拟的 (1!)...），以及一个保存数据的 sql 服务器。 现在我们有很多数据流量。我说的是几十万。所以我实际上什至不确定一台服务器是否相当安全，但我们公司并不是那么容易说服的。

现在我们最近遇到了很多问题。

请允许我详细定位，所以我不会遗漏任何东西：

我们的服务器有 5 个应用程序：

一个具有 3 个编排、12 个发送端口、16 个接收位置。 一个具有 4 个编排、32 个发送端口、20 个接收位置。 一个具有 4 个编排、24 个发送端口、20 个接收位置。 一个具有 47 个（是 47 个）编排、37 个发送端口、6 个接收位置。 一个具有通用应用程序和几个资源的应用程序。

自从我们使用 47 个编排部署应用程序后，问题就出现了。 许多这些编排使用分配形状，这些形状使用 c# 代码进行映射。这是因为我们使用 HL7 扩展，这有点特殊，所以通过使用 c# 代码和 xpath，映射更容易，因为很多这些模式看起来很相似。 c# 读入通过 xpath 接收的 XmlNodes，并返回 XmlNode，然后将其再次分配给 biztalk 消息。我不确定这是否是原因，但我想我会提到它。

发送和接收端口有很多不同的类型：文件、MQSeries、SQL、MLLP、FTP。 这些类型中的每一种都有不同的主机实例，以平衡负载。 我们的编排使用 BiztalkApplication 主机。

在这个服务器上还有几个脚本正在运行，主要是 ftp 上传脚本和一个 zipper 脚本，它以每日 zip 格式每半小时压缩一次文件，并在一个月后删除 zip 文件。我们在备份文件上使用这个 zipscript（我们备份了很多，备份也在我们的服务器上），我们这样做是因为服务器在将文件发送到有很多（很多）文件的位置时遇到问题，所以在文件被压缩成压缩包，这样会更好。

现在我们最近遇到的问题主要是两大问题：

我们最重要的问题如下。我们在队列中保留了一个包含大量消息的接收位置以进行测试。在我们启动这个使用 47 个编排的接收位置后，正在运行的服务实例开始摇摆不定。好吧，这很正常。假设大约有 10000 个，然后我们停止接收位置，看看 biztalk 如何处理这 10000 个实例。通常它们会很快下降，有时确实如此，但过了一段时间它开始“节流”，这意味着它们只是停止处理并且服务实例保持相同的数量，例如在 30 秒内它从 10000 下降到 4000 然后它保持在 4000 并且非常非常非常缓慢地降低，例如 5 分钟内 30 或其他东西。所以这意味着，其他应用程序的所有其他服务实例也都卡在这里，它们也没有被处理。

我们注意到，在重新启动主机实例后，实例数量再次快速下降。所以我们尝试选择性地重启不同的主机实例来定位问题。我们注意到最终重新启动文件发送/接收主机实例可以解决问题。所以我们认为文件发送会是问题所在。考虑到我们做了很多备份。所以我们用 mqseries 备份替换了文件类型备份。发生了同样的问题，有趣的是，重新启动文件发送/接收主机仍然可以解决问题。

在事件查看器中也找不到错误。

我们遇到的第二个问题是。有时在早上 6 点左右，所有或部分主机实例都会停止。

在事件查看器中，我们注意到以下错误（不止一个）：

URL 为“SQL://ZNACDBPEG/mdnd0001/”的接收位置“MdnBericht SQL”正在关闭。详细信息：“已超出错误阈值。接收位置正在关闭。”。

消息引擎未能将 URL 为“\m2mservices\Othello_import$\DataFilter Start*.xml”的接收位置“M2m Othello Export Start Bestand”添加到适配器“FILE”。原因：“FILE 适配器无法访问文件夹 \m2mservices\Othello_import$\DataFilter Start。 验证此文件夹是否存在。 错误：登录失败：未知用户名或密码错误。 ”。

FILE 适配器无法访问文件夹 \m2mservices\Othello_import$\DataFilter Start。 验证此文件夹是否存在。 错误：登录失败：未知用户名或密码错误。

尝试连接到服务器“ZNACDBBTS”上的“BizTalkMsgBoxDb”SQL Server 数据库失败。 错误：“用户 '' 登录失败。该用户未与受信任的 SQL Server 连接关联。”

此时似乎出现登录失败，因此其他服务也遇到问题，最终被关闭。

问题是，我们的用户是管理员，它的密码“有时”不可能是错误的。我们认为问题可能是由基础设施问题引起的，但这并不是真正的部门。

我知道这是一篇很长的帖子，但我们不知道该怎么做。添加另一台服务器并平衡负载会解决我们的问题吗？有没有办法衡量我们的平衡并知道从哪里开始分裂？负载等的正常数量是多少？

感谢任何答案，因为这些问题越来越严重，而且我们也处于最后期限。

非常感谢您的回复！

【问题讨论】：

我们也有同样的问题，请问您还有文件吗？

【参考方案1】：

您的直接问题是 BizTalk throttling feature。它应该帮助 BizTalk 在临时过载条件下生存。它的众多问题之一是您只能在性能监视器中看到节流启动，而不是在事件日志中。

你应该做什么：

将新应用程序与其他应用程序分开到不同的主机。限制在主机级别完成。因此，有问题的应用程序不会影响其余应用程序。 在上面的链接中了解如何禁用节流。 我们所做的是实施外部限制服务。以可消化的小数据包形式提供 BizTalk 接收位置。它很丑，但问题很丑。

更新评论：您有足够的主机实例。所以忽略这个建议。您可以在实例之间重新排序应用程序。但是没有明确的指导方针来做到这一点。所以它只是洗牌和猜测。 关于禁用节流的安全性。此功能在许多情况下没有多大意义。你必须研究它。检查您正在达到哪些限制参数（可以在性能监视器中看到）并决定如何更改阈值。

【讨论】：

禁用节流是否不安全？我注意到当它节流时，我们的 CPU 大约是 10-20%。这当然是荒谬的，当我们重新启动并且它工作正常时，它是 100%，所以这是正常的。我可以看到有 6 种不同的节流方式，我应该禁用所有这些吗？这是安全的吗？是有原因的吧？关于拆分主机实例。所以我应该将每个应用程序拆分为一个主机实例吗？我们现在有 20 个主机实例，所以如果我为每个应用程序拆分一个主机实例，我们只有 4 个主机实例而不是 20 个

【参考方案2】：

你有多少主机实例？

从行：

发送和接收端口有很多 不同类型：文件、MQSeries、 SQL、MLLP、FTP。这些类型中的每一个 有不同的主机实例，以 平衡负载。我们的 编排使用 Biztalk应用程序主机

听起来您有很多问题 - 我最近对 ​​BizTalk 自我节流的系统进行了审核，问题的部分原因是主机实例过多。每个主机实例都将自己的负载放在 BizTalk 消息框上，并占用至少 200mb 的内存。

阅读您的评论，您有 20 个 - 这太多了，会成为您问题的很大一部分。

一个好的起始主机设置是：

专门的跟踪主机 一个包含所有适配器接收处理程序的主机 一个包含所有编排的主机 一个包含所有适配器发送处理程序的主机 一个主机用于需要集群的适配器（如 FTP 和 MSMQ）

然后，您还可以考虑引入“实时”主机和批处理主机，这样您就可以调整实时主机以降低延迟。

如果已知不稳定，您也可以为特定应用程序设置主机，但一般不应该这样做。

【讨论】：

我们有大约 20 个主机实例。那么我们是否应该为每个应用程序拥有 1 个主机实例？因为我记得我们有一个问题是我们创建了一个额外的主机实例来解决这个问题。我再次不确定它是什么，所以也许将每个应用程序的主机实例分开仍然可以解决它。我说的对吗？

根据我的经验，20 个主机实例太多了。我在回答中添加了更多细节，概述了声音主机设置。

【参考方案3】：

我运行的 BizTalk 系统存在类似问题，并且可以理解您所看到的。我不知道是不是一样，但我想我会分享我的经验以防万一。

以同样的方式重新启动发送/接收似乎可以解决问题。就我而言，我发现与主机进程的内存使用直接相关。我使用性能计数器来查看给定主机何时因内存而受到限制。通过创建额外的主机，并在它们之间移动编排和端口，我能够缩小导致问题的业务集的范围。基本上在我的情况下，重新启动主机相当于最终的“垃圾收集”以释放内存。当然，直到有足够多的实例再次吞噬它。

恐怕我还没有解决这个问题，但是我发现了一些可以缓解这个问题的方法：

将内存提升到给定进程，以便不会发生或稍后发生限制 每个主机实例虽然信息丰富，但确实增加了开销。尝试将不是您的问题孩子的主机组合在一起，以减少内存占用。 硬件问​​题，内存很便宜

我在 perfmon 中每隔几分钟测量一次以下内容，以便诊断问题出在哪里：

BizTalk:MessageAgent(*)\进程内存使用量 (MB)

BizTalk:MessageAgent(*)\进程内存使用阈值

内存\可用 MBytes

还有一些其他的东西可以看看。确保任何自定义管道都使用良好的 BizTalk 内存做法（即没有隐藏在某处的 XML DOM 操作等）。同样理论上减少给定主机的线程数应该会降低它一次可以占用的内存量。我似乎对这个不太走运。正如其他人提到的那样，也许 BizTalk 节流覆盖了它，我不知道。此外，最后一点，如果您将 perfmon 结果转储到 csv，使用 Excel，您可以制作一些漂亮的内存使用图。这些可能有助于与管理层讨论购买更多硬件。这是假设您的问题也适合这种情况。

【参考方案4】：

由于您的所有答案的组合，我们暂时解决了这个问题。

我们将部分主机的进程内存使用限制参数设置得更高。

在我分析了所有主机的所有内存使用情况后，我们更好地划分了主机实例的平衡，这要归功于性能计数器以及使用名为 MsgBoxViewer 的工具。

现在我们正在尝试获得更多的物理内存，并希望还有一个额外的服务器或 64 位服务器。

感谢所有回复！

【参考方案5】：

我们最近在旧服务器的集群中安装了 64 位服务器。得益于此，我们可以更好地平衡内存，从而解决了很多问题。

虽然 64 位并没有给我们带来太多改进（除了更多的内存），因为它不能在 IBM MQ、MLLP、HL7 管道等上使用 64 位...

【参考方案6】：

其他答案对运行时性能调整很有帮助，但我也建议进行设计更改。

你说你在消息分配形状的编排中做了很多消息操作。

我建议将该代码移至专用转换。它们的重量要轻得多，并且可以更快地执行。您可以在这些地图中组合自定义xslt 和c# 来完成艰苦的工作。编排在开发、设计和测试方面的成本更高，在运行时性能方面的成本也更高。

然后，您可以使用转换进行消息转换，并将编排（移动消息分配代码后剩下的部分）留给编排。

使用转换而不是编排的额外好处是它们更易于测试。