通过

BizTalk Server 层的瓶颈

  • 项目

BizTalk 层可分为以下功能区域：

  • 接收

  • 处理

  • 传输

  • 跟踪

  • 其他

    对于这些方面，如果 CPU、内存和磁盘) (系统资源似乎已饱和，请根据应用程序的特征通过纵向扩展或横向扩展平台来升级服务器。 如果系统资源不饱和，请执行本部分中介绍的这些步骤。

接收位置中的瓶颈

例如，如果邮件在接收位置 (积聚，则文件接收文件夹) 会增大，这表明系统无法以足够快的速度吸收数据来跟上传入的负载。 这是由于内部限制造成的。 也就是说，如果订阅者无法足够快地处理数据，导致数据库表中积压工作累积，BizTalk Server会降低接收速率。 如果瓶颈是由硬件限制引起的，请尝试纵向扩展。 有关纵向扩展的详细信息，请参阅 BizTalk Server 2010 文档中的以下主题：

处理瓶颈

如果“主机队列 – 长度”性能计数器正在攀升，则表明业务流程完成速度不够快。 有关详细信息，请参阅本主题中的 Perfmon 计数器表。 这可能是由于内存争用或 CPU 饱和所致。

如果业务流程服务器是瓶颈，请使用 Perfmon 来标识来源。

如果服务器受到 CPU 的约束，请考虑以下情况：

  • 如果工作流很复杂，请考虑将业务流程拆分为多个较小的业务流程

    注意

    将一个业务流程拆分成多个工作流可能会导致额外的延迟并使复杂性增加。 多个工作流还可能导致发布到 BizTalkMsgBoxDb 和使用的消息数增加，从而给数据库带来额外的压力。

  • 如果使用复杂映射，请考虑是否可以将其移动到接收/发送端口。 请务必验证哪些端口具有额外的带宽。

  • 请考虑通过配置其他处理服务器来纵向扩展硬件或横向扩展。

传输瓶颈

如果托管发送适配器的服务器在资源 (（例如磁盘、内存或 CPU) ）上饱和，请考虑纵向扩展服务器或横向扩展到其他发送主机服务器。 如果目标（位于 BizTalk 外部）接收数据的速度不够快，发送层则可能成为瓶颈。 这将会导致消息在 MessageBox 数据库（应用程序 SendHostQ）中累积。

如果所有终结点都在拓扑范围内，请在目标位置隔离原因。 例如，确定 HTTP 位置是否以最佳方式配置为接收负载。 如果没有，请考虑横向扩展。此外，确定目标是否由于 BizTalk 传递的输出消息过多而增长。 如果是，可能需要维护计划来存档和清除目标消息。 目标文件夹中的大量文件可能会严重影响 BizTalk 服务将数据提交到磁盘驱动器的能力。

跟踪瓶颈

跟踪主机实例负责将业务活动监视 (BAM) 和运行状况和活动跟踪 (HAT) 数据从 MessageBox 数据库 (TrackingData 表) 移动到 BizTalk 跟踪和/或 BAM 主导入数据库表。 如果配置了多个 MessageBox 数据库，跟踪主机实例将为每个 MessageBox 数据库使用四个线程。

跟踪主机实例可能受 CPU 限制。 如果是，请考虑通过配置启用了主机跟踪的其他服务器来纵向扩展服务器或横向扩展服务器。 多个主机实例将自动对配置的多个 MessageBox 数据库进行负载均衡。 有关缩放的详细信息，请参阅主题 缩放解决方案 (https://go.microsoft.com/fwlink/?LinkId=158078) 。

如果 MessageBox 数据库中的 TrackingData 表变大，通常是因为 BizTalk 跟踪和/或 BAM 主导入数据库上的数据维护作业未按配置运行，导致 BizTalk 跟踪和/或 BAM 主导入数据库的增长。 当这些数据库变得太大后，可能会对跟踪主机将数据插入 TrackingData 表的能力产生负面影响。 这会导致跟踪的数据备份到 MessageBox 数据库表中。 TrackingData 表的增长会导致限制开始。

应仅启用应用程序所需的最小跟踪，因为这样将减少记录的数据量并降低跟踪瓶颈的风险。 有关禁用单个项（如业务流程和发送/接收端口）的跟踪设置的信息，请参阅 如何禁用跟踪 (https://go.microsoft.com/fwlink/?LinkId=160064) 。

其他

配置部署拓扑结构，以使不同的功能运行在专用的独立主机实例中。 这样，每个主机实例获取自己的资源集 (例如，在 32 位系统上、2GB 虚拟内存地址空间、句柄、线程) 。 如果服务器有足够的 CPU 余量和内存来托管多个主机实例，则可以将其配置为在同一物理计算机上运行。 如果没有，请考虑通过将功能移动到专用服务器进行横向扩展。 在多个服务器上运行相同的功能也可用于提供高可用性的配置。

BizTalk 系统性能计数器

Object 实例 计数器 监视目的
处理器 _Total 处理器时间百分比 资源争用
进程 BTSNTSvc 虚拟字节数 内存泄漏/膨胀
进程 BTSNTSvc 专用字节数 内存泄漏/膨胀
进程 BTSNTSvc 句柄计数 资源争用
进程 BTSNTSvc 线程计数 资源争用
物理磁盘 _实例 空闲时间百分比 资源争用
物理磁盘 _实例 Average Disk Queue Length 资源争用

CPU 争用

如果处理器饱和，可以通过将接收与发送和业务流程分开来碎片应用程序。 为此，请创建单独的主机，将主机映射到特定功能 (接收/发送/业务流程/跟踪) ，并将专用服务器添加到这些单独的主机。 业务流程功能通常占用大量 CPU。 如果配置系统，以便业务流程在单独的专用服务器上执行，这可以帮助提高整体系统吞吐量。

如果部署了多个业务流程，则可以将它们登记到不同的专用业务流程主机。 将不同的物理服务器映射到专用业务流程主机可确保不同的业务流程是隔离的，并且不会争用同一物理地址空间或同一服务器上的共享资源。

停止未使用的主机实例。 未使用的主机实例可以通过定期检查 MessageBox 中是否有要处理的消息来争夺 CPU 和内存资源。 此外，停止未使用的接收位置、发送端口和业务流程。

后台打印表增长

下游瓶颈和/或资源争用可能会导致假脱机开始过度增长，并降低整体性能。 有关详细信息，请参阅 如何识别 MessageBox Database1 中的“后台打印表增长”。

内存不足

高吞吐量情况可能会增加对系统内存的要求。 由于 32 位进程受其占用内存量的限制，因此建议将接收/进程/发送功能分离到单独的主机实例中，以便每个主机接收自己的 2GB 地址空间。 此外，如果多个主机实例在同一物理服务器上运行，则可以升级到 4/8GB 内存，以避免将数据从实际内存交换到磁盘。 长时间运行的业务流程可以保留更长的已分配内存。 这可能会导致内存膨胀和限制启动。 大型消息还会导致内存消耗过高。

通过降低特定主机的每个 CPU 值 的内部消息队列大小 和 进程内消息 值，可以缓解处理大型消息时出现的内存膨胀问题。

注意

如果担心延迟，应谨慎更改 内部消息队列大小 和 每个 CPU 的进程内消息 ，因为这可能会增加系统的端到端延迟。

磁盘争用

例如，如果磁盘 (饱和，) 大量 FILE/MSMQ 传输，请考虑升级到多个心轴，并使用 RAID 10 条带化磁盘。 此外，每当使用文件传输时，请务必确保接收和发送文件夹不会增长超过 50,000 个文件。

如果BizTalk Server限制传入数据进入系统，则接收文件夹可能会变大。 请务必从 send 文件夹中移动数据，以便此文件夹中的增长不会影响BizTalk Server写入其他数据的能力。 对于非事务性 MSMQ 队列，建议远程创建接收队列，以便在BizTalk Server减少磁盘争用。

远程非事务性队列配置还提供高可用性，因为可以群集化托管队列的远程服务器。

其他系统资源争用

根据传输的类型，可能需要为 HTTP (例如 MaxIOThreads、MaxWorkerThreads) 配置 IIS 等系统资源。

使用 ASP.NET 2.0 和 ASP.Net 4， <machine.config 文件中的 processModel autoConfig=“true”> 设置将自动配置以下设置以获得最佳性能：

  • 最大工作线程数

  • 最大 IO 线程数

  • httpRuntime 元素的 minFreeThreads 属性

  • httpRuntime 元素的 minLocalRequestFreeThreads 属性

  • connectionManagement> 元素的 maxConnection 属性 < (网络设置) 元素

    有关配置影响适配器性能的参数的详细信息，请参阅 processModel Elementhttps://go.microsoft.com/fwlink/?LinkId=158080 () ASP.NET 配置设置。

    有关可能影响BizTalk Server适配器的配置设置的详细信息，请参阅影响适配器性能的配置参数 (https://go.microsoft.com/fwlink/?LinkID=154200) 。

    除了优化BizTalk Server应用程序外，在同一服务器上运行的其他 ASP.NET 应用程序可能会影响整体性能。 优化所有 ASP.NET 应用程序以减少对系统资源的需求非常重要。 有关详细信息，请参阅 ASP.NET 性能 (https://go.microsoft.com/fwlink/?LinkId=158081) 。

    配置以获得最佳性能时，请考虑优化其他外部系统，例如消息引擎 (消息队列、MQSeries) 、应用程序、数据库、Active Directory 等，这些系统是整个 BizTalk 解决方案的一部分。 任何其他外部系统中的性能瓶颈都可能会对 BizTalk 解决方案产生负面影响。

下游瓶颈

如果下游系统无法足够快地从 BizTalk 接收数据，则此输出数据将备份到 BizTalk 数据库中。 这会导致膨胀，导致限制启动，收缩接收管道，并影响 BizTalk 系统的总体吞吐量。 这一点的直接指示是后台打印表的增长。 有关瓶颈和后台打印表的详细信息，请参阅 如何识别 MessageBox Database1 中的瓶颈。

限制的影响

限制最终将开始，以防止系统达到不可恢复的状态。 因此，可以使用限制来验证系统是否正常运行并发现问题的根源。 从限制状态确定瓶颈的原因后，请分析其他性能计数器以确定问题的根源。 例如，MessageBox 数据库上的高争用可能是由于 CPU 使用率过高，这是由于内存不足导致过度分页到磁盘造成的。 由于磁盘驱动器饱和，导致 MessageBox 数据库上的高争用也可能导致高锁争用。 虽然偶尔的限制对性能没有重大威胁，但永久性限制可能表明存在更严重的潜在问题。 有关BizTalk Server将使用限制的条件的详细信息，请参阅如何BizTalk Server实现主机限制 (https://go.microsoft.com/fwlink/?LinkID=155286) 。

有关BizTalk Server限制如何帮助管理可用资源的使用并最大程度地减少资源争用的详细信息，请参阅通过主机限制优化资源使用情况 (https://go.microsoft.com/fwlink/?LinkID=155770) 。

BizTalk 应用程序计数器

Object 实例 计数器 说明
BizTalk 消息传送 RxHost Documents received/sec 传入速率
BizTalk 消息传送 TxHost Documents processed/Sec 传出速率
XLANG/s 业务流程 PxHost Orchestrations Completed/Sec. 处理速率
BizTalk ：MessageBox：常规计数器 MsgBoxName 后台打印大小 所有主机队列的累积大小
BizTalk ：MessageBox：常规计数器 MsgBoxName Tracking Data Size MessageBox 上 TrackingData 表的大小
BizTalk:MessageBox:主机计数器 PxHost:MsgBoxName Host Queue - Length 特定主机队列中的消息数
BizTalk:MessageBox:主机计数器 TxHost:MsgBoxName Host Queue - Length 特定主机队列中的消息数
BizTalk：消息代理 RxHost 数据库大小 发布 (PxHost) 队列的大小
BizTalk：消息代理 PxHost 数据库大小 发布 (TxHost) 队列的大小
BizTalk：消息代理 HostName Message delivery throttling state 影响 XLANG 和出站传输
BizTalk：消息代理 HostName 消息发布限制状态 影响 XLANG 和入站传输

从哪里开始？

监视每个主机实例 的消息传递限制状态 和 消息发布限制状态 是一个很好的起点。 如果这些计数器的值不为零，则表示 BizTalk 系统中存在限制，可以进一步分析瓶颈的原因。 有关其他性能计数器的说明，请参阅 数据库层中的瓶颈。

业务流程引擎性能计数器

强烈建议微调业务流程运行时设置，因为连续业务流程解除冻结/解除冻结和持久性点可能会对整体性能产生严重影响。 在测试可能包含多个持久性点和事务范围的复杂业务流程时，必须使用以下计数器。

计数器 注释
Orchestrations dehydrated/sec 平均每秒冻结的业务流程数。
Orchestrations rehydrated/sec 平均每秒解除冻结的业务流程数。
Persistence points/sec 平均每秒持久化业务流程实例的次数。
Orchestrations resident in memory 当前以主机实例为宿主的业务流程实例的数量。
Orchestrations completed/sec 平均每秒完成的业务流程数。
Orchestrations suspended/sec 平均每秒挂起的业务流程数。
Transactional scopes committed/sec 平均每秒提交的事务作用域数。
Transactional scopes aborted/sec 平均每秒中止的事务作用域数。
Transactional scopes compensated/sec 平均每秒补偿的事务作用域数。

积压工作积压

对于 1-1 部署方案，其中 1 条消息接收导致处理并传输 1 条消息，如果传出速率不等于传入速率，则系统中会出现积压工作。 在这种情况下，可以监视后台处理程序大小。 确定传出速率瓶颈的原因时，一次运行单个用例方案。 隔离业务流程、接收位置，并将位置发送到单独的主机。

将 BizTalk：Message Box：Host 计数器添加到性能监视器日志以监视主机。 主机队列 - 长度： 计数器跟踪特定主机队列中的消息总数。 如果一个或多个这些计数器随着时间推移而继续增长，请特别注意这些主机执行的项目。

如果 Spool 呈线性增长，请确定哪个应用程序队列负责 Spool 增长。

如果应用程序队列没有增长，并且 Spool 继续增长，则可能意味着清除作业无法跟上。 如果代理未运行或SQL Server上存在其他系统资源争用，则会发生此情况。

如果其中一个应用程序队列正在增长，请诊断此增长的原因。 监视系统上无法排出特定应用程序队列的系统资源 (例如，由于服务器) CPU 不足，业务流程主机 Q 正在增长。 此外，验证特定主机实例的限制计数器的值。

如果 BizTalk：Message Agent 消息传递限制状态和消息发布限制状态性能计数器不为零，检查值以确认限制的原因 (例如，超出内存阈值、未完成消息计数过高等) 。

Stand-Alone Profiler

可以使用性能计数器在高级别上检测瓶颈的位置。 但是，缩小范围后，可能需要更仔细地检查代码以帮助缓解问题。 Visual Studio 2010 附带的 Stand-Alone Profiler 是一种非常有用的工具，可帮助诊断代码在其大部分周期中花费的位置。 有关详细信息，请参阅

L2/L3 缓存

从硬件的角度来看，使用板载 CPU 缓存可以获得最大的好处。 较高的 CPU 高速缓存可增加高速缓存命中率，减少系统在内存和磁盘之间读/写数据页的需要。

64 位性能瓶颈

64 位系统的性能表现可能不如 32 位系统获得的性能。 这是可能的一些原因，其中最重要的一个是内存。

在具有 2 GB 内存的 32 位系统上测量性能，并将结果与具有 2 GB 内存的类似 64 位系统进行比较并不是比较相同的。 64 位系统看起来是磁盘 I/O 绑定 (低的磁盘空闲时间百分比 & 磁盘队列长度) 和 CPU 限制 (最大 CPU 和高上下文切换) 。 但是，这不是因为在 64 位系统上执行文件 I/O 的成本更高。

64 位系统的内存密集型 (64 位寻址) 这会导致操作系统消耗 2 GB 可用内存中的大部分。 发生这种情况时，大多数其他操作会导致对磁盘进行分页，从而给文件子系统带来压力。 因此，系统花费 CPU 周期来分页内存和代码，并受高磁盘延迟成本的影响。 它表现为更多的磁盘争用和更多的 CPU 占用。

缓解此问题的方法是通过升级内存来纵向扩展服务器。 纵向扩展到 8 GB 是理念，但是，添加更多内存无助于提高吞吐量，除非问题的根源是内存不足导致 CPU 不足。

使用 BAM 识别瓶颈和高延迟问题

当低延迟很重要时，可以使用 BAM 来测量系统完成BizTalk Server系统中每个阶段所需的时间。 尽管可以使用 HAT 来调试消息的状态并诊断路由消息中问题的根源，但可以使用 BAM 跟踪消息流的各个点。 通过创建使用延续定义活动的 BAM 跟踪配置文件，可以测量系统不同部分之间的延迟，以帮助跟踪工作流过程中最昂贵的阶段。

可以使用 HAT 中的业务流程调试器查询挂起的实例，在调试模式下恢复该实例，并使用“技术详细信息”视图添加适当的断点。 这些操作允许您分步跟踪活动和调试消息。

可以设置断点来跟踪以下事件：

  • 业务流程的启动和结束

  • 形状的启动和结束

  • 消息的发送或接收

  • 例外

    在每个断点，您可以查看有关局部变量、消息及其属性、端口和角色链接的信息。

另请参阅

查找并消除瓶颈