BizTalk服务器问题
我们公司有一个biztalk服务器（一个虚拟的（1！）…）和一个保存数据的sql server。 现在我们有很多数据流量。 我说的是成千上万。 所以我实际上不确定一台服务器是否相当安全，但我们的公司并不那么容易说服。
最近我们遇到了很多问题。
请允许我详细说明，所以我没有遗漏任何东西：
我们的服务器有5个应用：
- 一个有3个编排，12个发送端口，16个接收位置。
- 一个有4个编排，32个发送端口，20个接收位置。
- 一个有4个编排，24个发送端口，20个接收位置。
- 一个有47个（是47个）编排，37个发送端口，6个接收位置。
- 一个具有几个资源的常见应用程序。
自从我们使用47个业务流程部署应用程序以来，我们遇到了问题。 很多这些编排使用赋值形状，使用c＃代码进行映射。 这是因为我们使用HL7扩展，这有点特殊，所以通过使用c＃code和xpath，映射更容易，因为很多这些模式看起来很相似。 c＃读入通过xpath接收的XmlNodes，并返回XmlNode，然后再将其分配给biztalk消息。 我不确定这可能是原因，但我想我会提到它。
发送和接收端口有许多不同的类型：文件，MQSeries，SQL，MLLP，FTP。 每种类型都有不同的主机实例，以平衡负载。 我们的业务流程使用BiztalkApplication主机。
在这个服务器上还运行了几个脚本，主要是ftp上传脚本和拉链脚本，每天拉链文件每半小时压缩一次，并在一个月后删除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。validation此文件夹是否存在。错误：登录失败：未知用户名或密码错误。”。
FILE适配器无法访问文件夹\ m2mservices \ Othello_import $ \ DataFilter Start。 确认此文件夹存在。 错误：登录失败：未知的用户名或密码错误。
尝试连接到服务器“ZNACDBBTS”上的“BizTalkMsgBoxDb”SQL Server数据库失败。 错误：“用户登录失败”。用户未与受信任的SQL Server连接关联。
看起来此时登录失败，因此其他服务也遇到问题，并最终关闭。
问题是，我们的用户是管理员，并且“有时”密码错误是不可能的。 我们已经得出结论，问题可能是由于基础设施问题，但这不是真正的部门。
我知道这是一个很长的post，但我们不确定该怎么做。 添加另一台服务器并平衡负载会解决我们的问题吗？ 有没有办法确保我们的平衡，并知道从哪里开始分裂？ 什么是正常的负载等？
我很感激任何答案，因为这些问题越来越严重，我们也在截止日期前。
非常感谢您的回复！
您当前的问题是BizTalk 限制 function 。 它应该帮助BizTalk在临时过载条件下生存。 其中一个问题是，您只能在性能监视器中看到限制启动，而不是在事件日志中。
你应该做什么：
- 将新应用程序分离到与其他应用程序不同的主机。 限制是在主机级别完成的。 因此，有问题的应用程序不会影响其余的应用程序。
- 阅读有关如何在上面的链接中禁用限制的内容。
- 我们所做的是实施外部限制服务。 这将BizTalk接收位置提供给易消化的小包。 它很难看，但问题很难看。
更新评论：您有足够的主机实例。 所以忽略这个建议。 您可以在实例之间重新排序应用程序。 但是没有明确的指导方针。 所以它只是在洗牌和猜测。
关于禁用限制的安全性。 在许多情况下，此function没有多大意义。 你必须研究它。 检查您正在命中哪个限制参数（这可以在性能监视器中看到）并确定如何更改阈值。
你有几个主机实例？
从行：
发送和接收端口有许多不同的类型：文件，MQSeries，SQL，MLLP，FTP。 每种类型都有不同的主机实例，以平衡负载。 我们的业务流程使用BiztalkApplication主机
听起来你有很多 – 我最近对BizTalk自我限制的系统进行了审计，问题部分是由于主机实例太多。 每个主机实例都将自己的负载放在BizTalk消息框上，并且至少要占用200mb的内存。
阅读你的评论，你有20个 – 这太多了，并且会成为你问题的重要组成部分。
一个好的启动主机设置将是：
- 专用的跟踪主机
- 一个主机，包含适配器的所有接收处理程序
- 一个包含所有业务流程的主机
- 一个主机，包含适配器的所有发送处理程序
- 一个需要集群的适配器主机（如FTP和MSMQ）
然后，您还可以考虑引入“实时”主机和批量主机，这样您就可以调整实时主机以实现低延迟。
如果已知不稳定，您也可以拥有特定应用程序的主机，但通常不应该这样做。
我运行的BizTalk系统有类似的问题，可以理解你所看到的。 我不知道它是否相同，但我想我会分享我的经验。
以同样的方式重新启动发送/接收似乎可以解决问题。 在我的情况下，我发现主机进程与内存使用率直接相关。 我使用性能计数器来查看给定主机何时受到内存限制。 通过创建额外的主机，并在它们之间移动编排和端口，我能够缩小导致问题的业务集。 基本上在我的情况下，重新启动主机相当于释放内存的最终“垃圾收集”。 这当然是直到有足够的实例再次吞噬它。
我担心我还没有解决这个问题，但我找到了一些缓解这个问题的方法：
- 将内存提升到给定进程，以便不会发生限制或稍后发生限制
- 每个主机实例虽然提供了信息，但确实有一个额外的开销。 尝试将不是您的问题儿童的主机组合在一起，以减少内存占用量。
- 抛出硬件问题，ram很便宜
-
我每隔几分钟在perfmon中测量以下内容，以便我可以诊断出问题所在：
BizTalk：MessageAgent（*）\进程内存使用量（MB）
BizTalk：MessageAgent（*）\进程内存使用量阈值
内存\可用MBytes
还有一些其他的事情要看。 确保任何自定义管道使用良好的BizTalk内存实践（即没有隐藏在某处的XML DOM操作等）。 理论上，减少给定主机的线程数也应该降低它一次可以占用的内存量。 我似乎对这个没有太多运气。 也许正如其他人提到的那样，BizTalk限制会超越它，我不知道。 另外，最后一点，如果将perfmon结果转储到csv，使用Excel可以制作一些漂亮的内存使用图。 这些可能有助于与管理层讨论购买更多硬件。 这假设您的问题也适合这种情况。
由于所有答案的组合，我们暂时解决了问题。
我们将某些主机的进程内存使用限制参数设置得更高。
在分析了所有主机的所有内存使用情况后，我们更好地划分了主机实例的余额，这要归功于性能计数器以及使用名为MsgBoxViewer的工具。
现在我们正试图获得更多的物理内存，并希望还有一台额外的服务器或64位服务器。
感谢所有回复！
我们最近使用旧服务器在群集中安装了64位服务器。 多亏了这一点，我们可以更好地平衡内存，从而解决了很多问题。
虽然64位没有给我们太多的改进（除了更多的内存），因为它不能在IBM MQ，MLLP，HL7管道等上使用64位……
其他答案有助于运行时性能调整，但我也建议进行设计更改。
您说您在消息分配形状的业务流程中进行了大量的消息操作。
我建议将该代码移动到专用转换。 它们重量更轻，可以更快地执行。 您可以在这些地图中组合自定义xslt和c#来完成艰苦的工作。 业务流程在开发，设计和测试方面的成本更高，而且在运行时性能方面的成本更高。
然后，您可以使用转换进行消息转换，并将编排（在将消息分配代码移动后剩下的内容）留给业务流程。
使用变换而不是编排的额外好处是它们更易于测试。