C# BizTalk server问题

我们公司有一个biztalk server（一个虚拟的服务器（1！）…），还有一个sql server，用于保存数据。 现在我们有很多数据流量。我说的是数十万。所以我甚至不确定一台服务器是否相当安全，但我们公司并不是那么容易说服

最近我们有很多问题

请允许我详细介绍一下，这样我就不会遗漏任何东西：

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

• 一个具有3个业务流程、12个发送端口和16个接收位置
• 一个具有4个业务流程、32个发送端口和20个接收位置
• 一个具有4个业务流程、24个发送端口和20个接收位置
• 一个包含47个（是47个）业务流程、37个发送端口、6个接收位置
• 一个具有公共应用程序和一些资源的应用程序

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

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

在这台服务器上，还有一些脚本正在运行，主要是ftp上传脚本&还有一个zipper脚本，它在每天的zip中每半个小时对文件进行一次zip，并在一个月后删除zip文件。我们在备份文件上使用这个zipscript（我们备份了很多，备份也在我们的服务器上），之所以这样做是因为服务器在将文件发送到有很多文件的位置时遇到了问题，所以在将文件缩减为zips后，效果会更好

现在我们最近遇到的问题主要有两个：

• 我们最重要的问题如下。我们在一个队列中保留了一个接收位置，其中包含大量消息以供测试。在我们启动这个使用47个业务流程的接收位置之后，正在运行的服务实例开始运行。好的，这很正常。假设大约10000个，然后停止接收位置，查看biztalk如何处理这10000个实例。通常情况下，它们会下降得很快，有时会下降，但过了一段时间，它开始“节流”，这意味着它们停止处理，服务实例保持在相同的数量，例如在30秒内，它从10000下降到4000，然后保持在4000，并且下降得非常缓慢，比如5分钟后30分钟左右。这意味着，其他应用程序的所有其他服务实例也都被困在这里，并且它们也没有被处理

我们注意到，在重新启动主机实例后，实例号又快速下降。因此，我们尝试有选择地重新启动不同的主机实例来定位问题。我们注意到，最终重新启动文件发送/接收主机实例就可以做到这一点。所以我们认为文件发送是个问题。我们做了很多备份。因此，我们将文件类型备份替换为mqseries备份。同样的问题也发生了，有趣的是，重新启动文件发送/接收主机仍然可以解决问题

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

• 第二个问题是。有时在上午6点左右，所有或部分主机实例都被停止

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

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

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

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

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

此时似乎出现了登录失败，并且由于它，其他服务也遇到了问题，最终它们被关闭

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

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

我很感激任何答案，因为这些问题越来越严重，我们也在最后期限上

---

非常感谢您的回复

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

你应该做什么：

将新应用程序分离到与其他应用程序不同的主机。节流完成