BizTalk 2016 sFTP WinSCP接收位置停止，服务主机未自动重启求助

我之前在处理BizTalk集群环境的SFTP适配器问题时，踩过几乎一模一样的坑，结合你的配置细节（2台服务器集群、CU5+FP3、27个WinSCP SFTP接收位置），给你梳理几个针对性的排查和解决步骤：

1. 先排查SFTP连接并发是否超限 #

你给每个接收位置设了连接限制=5，但27个接收位置分散连6台服务器，等于单台SFTP服务器可能被多个接收位置同时发起连接，总并发数很可能超过了对方服务器的最大允许连接数——这时候SFTP服务器会直接拒连，进而导致BizTalk的服务主机因连接异常崩溃。

• 先去查每台SFTP服务器的系统配置，确认它的最大允许连接数；
• 核算BizTalk这边对应同一SFTP服务器的所有接收位置的连接限制总和，确保不超过对方上限；
• 临时先把单个接收位置的连接限制降到2-3，缓解并发压力，看是否还会出现故障。

2. 修复服务主机自动重启的机制 #

事件日志说会自动重启但没执行，这大概率是BizTalk的主机配置或权限问题：

• 打开BizTalk管理控制台，找到运行SFTP适配器的接收主机，右键→属性→重启选项卡，确认「启用自动重启」已勾选，并且设置了合理的重启规则（比如5分钟内尝试重启3次）；
• 检查Host Instance运行的账户权限：必须要有本地管理员权限，同时要能访问BizTalk管理数据库，不然它没权限执行重启操作；
• 先手动重启一次Host Instance，看接收位置是否能恢复，同时盯着事件日志，看有没有“权限不足”这类导致重启失败的报错。

3. 升级WinSCP SFTP适配器版本 #

BizTalk 2016 CU5+FP3的环境下，旧版WinSCP适配器存在连接泄漏的Bug，高并发场景下很容易耗尽资源导致服务主机挂起：

• 确认你用的是适配BizTalk 2016的最新版WinSCP适配器，旧版本的连接泄漏问题在新版里已经被修复；
• 要是适配器支持的话，在接收位置配置里开启「连接池」和「空闲连接超时」，让适配器自动释放闲置连接，避免资源耗尽。

4. 监控并调整服务主机的资源回收策略 #

运行2小时才出问题，大概率是服务主机的资源（内存、句柄）被耗尽导致挂起：

• 用Windows性能监视器（PerfMon）监控Host Instance对应的BTSNTSvc.exe进程，看故障前是否出现CPU、内存、句柄数飙升的情况；
• 打开BizTalk管理控制台→主机属性→回收选项卡，设置内存限制（比如当内存超过2GB时自动回收），或者定时回收（比如每天凌晨），避免资源耗尽。

5. 查SFTP服务器端的日志 #

有时候问题出在对方服务器上：

• 去6台SFTP服务器上查系统日志或SFTP服务日志，看是否有针对BizTalk服务器IP的连接拒绝、超时或强制断开的记录；
• 要是SFTP服务器有连接超时设置，把BizTalk接收位置的「连接超时」配置改成和对方匹配，避免因超时而导致连接异常。

临时应急方案 #

要是以上排查还在进行中，可以先建一个Windows定时任务，每1.5小时自动重启对应的BizTalk Host Instance，先保证业务不中断，后续再彻底解决问题。

内容的提问来源于stack exchange，提问作者David Troska