识别 BizTalk 层中的瓶颈

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

• 收货

• 处理中

• 传输

• 跟踪

• 其他

  对于这些区域，如果系统资源（CPU、内存和磁盘）似乎饱和，请通过纵向扩展来升级服务器。 如果系统资源不饱和，请执行以下步骤。

接收位置中的瓶颈

如果消息开始在接收位置堆积（例如，文件接收文件夹中的文件数量增加或传出队列未能足够快地清空），这表明系统无法以足够快的速度吸收数据，从而无法跟上传入负载的节奏。这可能是由于内部节流机制所致（如果订阅者无法及时处理数据，导致数据库表中产生积压），此时BizTalk会降低接收速率。 如果由于硬件限制而造成瓶颈，请尝试纵向扩展。 通过将一个主机实例（服务器）添加到与接收处理程序关联的主机中，也可以实现扩展。 使用 Perfmon 监视系统上的资源利用率。 请务必确认外部接收位置不是瓶颈的原因。 例如，由于磁盘 IO 高，远程文件共享可能会饱和。可能导致服务器托管的远程传出队列不至于饱和的条件包括：用于生成 HTTP/SOAP 负载的客户端在线程上没有耗尽。

处理过程中的瓶颈

如果主机队列 - 长度计数（详情参见下表的 Perfmon 计数器）正在攀升，则表示协调过程的完成速度不够快。 这可能是由于内存争用或 CPU 饱和。

如果编排服务器是瓶颈，请使用 Perfmon 识别源头。

如果服务器的性能受限于 CPU，请考虑以下事项：

• 如果工作流很复杂，请考虑将其拆分为多个较小的编排。

  注释

  将业务流程拆分为多个工作流可能会导致额外的延迟并增加复杂性。

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

• 请考虑纵向扩展硬件，或者如果可能考虑通过配置其他处理服务器进行横向扩展。

传输瓶颈

如果发信服务器资源（例如磁盘、内存、CPU）已饱和，请考虑升级服务器，或者如果可能，请考虑扩展至其他发送主机服务器。 如果目标（BizTalk 外部）无法足够快地接收数据，则发送层可能会成为瓶颈。 这将导致消息在 MessageBox 数据库（Application SendHostQ）中累积。

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

跟踪瓶颈

跟踪主机实例负责将 BAM 和跟踪消息事件与服务实例数据从 MessageBox 数据库（TrackingData 表）转移到 BizTalkDTADb 数据库表和/或 BAMPrimaryImport 数据库表。 如果配置了多个 MessageBox 数据库，跟踪主机实例将为每个 MessageBox 使用四个线程。

此主机实例可能会由于 CPU 限制而影响性能。 如果是这种情况，请考虑通过配置启用了主机跟踪的其他服务器来纵向扩展服务器或横向扩展。 多个主机实例将自动平衡配置的多个 MessageBox 的负载。

如果 MessageBox 数据库中的 TrackingData 表开始备份，通常是因为 BizTalkDTADb 和/或 BAMPrimaryImport 数据库上的数据维护作业未按配置运行，从而导致 BizTalkDTADb 和/或 BAMPrimaryImport 数据库的增长。 这些数据库增长过大后，可能会对跟踪主机将数据插入这些表中的能力产生负面影响，从而导致跟踪数据在 MessageBox 数据库表中备份。 MessageBox-TrackingData> 表的增长将导致流量控制启动。

其他

配置部署拓扑，以便不同的功能在专用隔离主机实例中运行。 这样，每个主机实例都会获取自己的一组资源（在 32 位系统上，包括 2GB 虚拟内存地址空间、句柄和线程）。 如果服务器足够强大（足够的 CPU 头空间、内存）来托管多个主机实例，则可以将其全部配置为在同一物理计算机上运行。 否则，还可以通过将功能移动到专用服务器来轻松横向扩展。 在多台服务器上运行相同的功能也可用于提供高度可用的配置。

BizTalk 系统性能计数器

CPU 争用

如果处理器饱和，请考虑通过分离接收与发送和业务流程来分段应用程序。 实现此目的的方法是创建单独的主机，将这些主机映射到特定功能（接收/发送/业务流程/跟踪），并将专用服务器添加到这些单独的主机。 协调功能通常被认为是CPU密集型的，因此配置系统，使协调功能在单独的专用服务器上执行，有助于提高整体系统吞吐量。

如果部署了多个编排过程，可以将它们分配到不同的专用编排主机。 将不同的物理服务器分配给专用 Orchestration-Hosts，确保不同的编排得到隔离，并且不会在同一物理地址空间或同一服务器上竞争共享资源。

内存饥饿

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

通过降低特定主机的内部消息队列大小和每个 CPU 的进程内消息值，可以克服此内存膨胀问题。

磁盘争用

如果磁盘已达到饱和状态（例如文件/MSMQ 传输），请考虑升级为多个读写头，并将磁盘进行 RAID 1+0 条带化。 此外，每当使用 FILE 传输时，请务必确保文件夹（接收和发送）不会增大太大（>50,000 个文件）。

如果 BizTalk Server 选择限制传入数据进入系统，则“接收”文件夹可能会增大，原因如下所述。 从发送文件夹中移动数据也很重要，以便此文件夹中的增长不会影响 BizTalk Server 写入其他数据的能力。 对于非事务性 MSMQ 队列，建议远程创建接收队列，以便在 BizTalk 服务器上减少磁盘争用。

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

其他系统资源争用

根据配置的传输性质，可能需要为 HTTP/SOAP 配置系统资源，例如 IIS 这样的系统资源（例如 MaxIOThreads、MaxWorkerThreads）。

下游瓶颈

如果下游系统无法从 BizTalk 足够快速地接收数据，那么这些输出数据将在 BizTalk 数据库中堆积，从而导致系统膨胀。此膨胀会触发限流机制，进而缩小接收通道，最终影响 BizTalk 系统的整体吞吐量。 直接表明这一点将是后台处理程序的增长。

节流影响

限速最终将启动，以保护系统免遭不可恢复的状态。 因此，限流是验证系统是否正常运行并发现问题来源的合适方法。 从限制状态确定瓶颈原因后，分析其他性能计数器，向下钻取问题的根源。

例如，MessageBox 数据库上的高争用可能是因为 CPU 使用率过高引起的。这种高使用率可能由于过多的分页至磁盘引起，而过多分页至磁盘又可能是由于内存不足造成的。 MessageBox 上的高争用可能是由于高锁争用引起的，而高锁争用又可能是由磁盘驱动器过于饱和导致的。

BizTalk 应用程序计数器

我应从哪里开始？

监视 消息传送限制状态 和每个主机实例 的消息发布限制状态 通常是一个很好的开始位置。 如果这些计数器的值不为零，则表明限制发生在 BizTalk 系统中，并且有可能进一步分析瓶颈的原因。 有关其他性能计数器的说明，请参阅 “识别性能瓶颈”。

积压积累

对于 1-1 部署情景，当接收到 1 条消息导致处理和传输 1 条消息时，如果传出速率不等于传入速率，系统中的某个位置会生成积压。 这种情况下，可以监视缓存大小。

如果 Spool 呈线性增长，则可以通过验证哪个应用程序队列引起了 Spool 增长来进一步深入分析。

如果没有任何应用程序队列正在增长，并且 Spool 继续增长，则可能意味着由于代理未在 SQL 服务器上运行或其他系统资源争用，清除作业无法跟上。

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

如果传递/发布状态不为零，请检查该值以确认限速的原因（例如，超出内存阈值、未处理的消息计数过高等）。

F1 探查器

通过使用性能计数器，可以快速在宏观层面检测到瓶颈位置。 但是，一旦确定问题范围，可能需要进一步深入研究代码，以帮助解决问题。 Visual Studio 随附的 F1 分析器可能成为一个非常有帮助的工具，有助于诊断代码大部分运行周期消耗的位置。

符号对于帮助创建更有意义的堆栈（尤其是对于非托管代码）非常重要。 例如，F1-Profiler 可以帮助确定调用数以及 API 调用返回所需的时间。 进一步向下钻取堆栈，可以检测高延迟的根本原因。 它可能是对数据库查询的阻塞调用，也可能只是等待一个事件的调用。

L2/L3 缓存

可以从硬件角度获得的最大好处是利用载入 CPU 缓存。 更高的 CPU 缓存有助于提高缓存命中率，减少系统将数据在内存和磁盘之间分页的需求。

64 位性能瓶颈

64 位系统上的性能可能低于 32 位系统上可实现的性能。 这可能是由于几个原因，最重要的一个是内存。

在具有2 GB内存的32位系统上测量性能，并将结果与具有相同内存的64位系统上能够实现的结果进行比较，并不是一个真正公平的对比。 64 位系统似乎是磁盘 IO 绑定（低 % 磁盘空闲时间和高磁盘队列长度）和 CPU 绑定（最大 CPU 和高上下文切换）。 但是，这不是因为对 64 位系统上执行文件 IO 的成本更高。

64 位系统更占用内存（64 位寻址），这会导致 OS 占用 2 GB 可用内存中的大多数。 一旦发生这种情况，大多数其他操作会导致磁盘分页，从而给文件子系统造成压力。 系统现在不仅花费 CPU 周期来分页调入/调出内存中的数据和代码，还受到高磁盘延迟成本的影响。 这本身表现为磁盘争用较高和 CPU 消耗量更高。

缓解此问题的方法是通过升级内存（理想情况下为 8 GB）来纵向扩展服务器。 但是，除非问题的根源是由于内存不足导致的 CPU 资源匮乏，否则添加更多内存不会有助于提高吞吐量。

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

在低延迟很重要的情况下，可以使用 BAM 来测量系统在 BizTalk 系统中完成每个阶段所需的时间。 尽管跟踪的消息事件和服务实例数据可用于调试消息的状态并诊断路由消息中问题的来源，但 BAM 可用于通过消息流跟踪各种点。 通过创建 BAM 跟踪配置文件（定义具有延续的活动），可以测量系统不同部分之间的延迟，以帮助跟踪工作流中资源耗费最多的阶段。