使用适用于BizTalk Server的 PAL) 工具 (日志性能分析生成具有性能计数器的报告和图表

项目
09/28/2023

PAL (日志性能分析) 工具读取性能监视器计数器日志 (任何已知格式) ，并使用 () 提供的复杂但已知的阈值对其进行分析。该工具生成基于 HTML 的报告，该报表以图形方式绘制重要性能计数器的图表，并在超过阈值时引发警报。阈值最初基于 Microsoft 产品团队（包括BizTalk Server和 Microsoft 支持成员）定义的阈值。此工具不能替代传统的性能分析，但它可以自动分析性能计数器日志，从而节省时间。 PAL 工具：

分析阈值的性能计数器日志
对于大型 Perfmon 日志很有用
通过分析阈值来识别BizTalk Server和操作系统性能计数器瓶颈
可扩展，可对任何性能计数器执行分析
可用于帮助编写自己的计数器

可在 GitHub 免费下载 PAL。它需要 Microsoft 日志分析程序。日志分析器是一种功能强大、通用的工具，可提供对基于文本的数据（如日志文件、XML 文件和 CSV 文件）以及 Windows 操作系统上的关键数据源（如事件日志、注册表、文件系统和 Active Directory® 目录服务）的通用查询访问。你可能想要使用此工具来查询大量的日志记录信息。可以下载日志分析器工具。

将 PAL 与不同语言的性能计数器日志配合使用

PAL 工具仅以英语分析性能计数器日志。若要将 PAL 工具与其他语言的性能计数器日志配合使用，必须先将日志翻译为英语。可以使用 Perfmon 日志翻译器将原始性能计数器日志文件转换为英语。

了解适用于 Microsoft BizTalk Server 2010 的 PAL 工具报告

PAL 工具提供 Windows 操作系统、Microsoft SQL Server和BizTalk Server阈值的 Perfmon 日志分析。本部分介绍 PAL 工具中BizTalk Server阈值报告中的大部分分析。

注意

本主题很长，以便可以在一个位置包含有关 PAL 工具的综合信息，以便于参考。

PAL 工具报告以下分析和阈值。

分析类型和名称	分析说明
磁盘：内核转储的磁盘可用空间	此分析检查以确保有足够的可用磁盘空间供操作系统将所有内存转储到磁盘。如果磁盘空间不足，操作系统将无法创建 memory.dmp 文件，该文件是分析内核转储的根本原因所必需的。
磁盘：逻辑/物理磁盘接口分析	此分析将查看每个物理磁盘的空闲时间。磁盘的空闲时间越长，磁盘的使用就越少。在逻辑磁盘中使用一个磁盘时，最好使用此计数器。 “百分比空闲时间”报告磁盘处于空闲状态的采样间隔内的时间百分比。参考：排除 Disk-Bound 问题
磁盘：逻辑/物理磁盘读取/写入延迟分析	Windows 检测磁盘性能瓶颈的最可靠方法是测量其响应时间。如果响应时间大于 0.025 (25 毫秒) （这是一个保守的阈值），则可能会出现影响用户的明显减速和性能问题。有关详细信息，请参阅本主题中的逻辑/物理磁盘读/写延迟分析。
磁盘：逻辑磁盘传输/秒	“磁盘传输/秒”是磁盘上的读取和写入操作速率。此分析的阈值检查查看是否有任何逻辑磁盘显示 I/O 操作) 响应时间不佳 (大于 25 毫秒。如果为 true，则每秒的磁盘传输数应为或高于 80。如果没有，则需要调查磁盘体系结构。磁盘 I/O 不佳的最常见原因是 SAN 上的 LUN 过载。有关详细信息，请参阅本主题中的逻辑磁盘传输/秒。
磁盘：LogicalDisk 可用空间百分比	“% 可用空间”是所选逻辑磁盘驱动器上可用的总可用空间的百分比。在可用磁盘驱动器空间小于 30% 之前，性能不会受到影响。使用 70% 的磁盘驱动器时，剩余可用空间位于磁盘驱动器中心的磁盘轴上，该驱动器以较低的性能级别运行。缺少可用磁盘空间可能会导致磁盘性能严重。
磁盘：处理 IO 数据操作数/秒和进程 IO 其他操作/秒分析	这些计数器对进程生成的所有 I/O 活动进行计数，以包括文件、网络和设备 I/O。当进程每秒执行超过 1,000 个 I/O 时，这些分析检查并将其标记为警告。这些分析最好与其他分析（例如磁盘分析）相关联，以确定哪些进程可能涉及 I/O 活动。
内存：可用内存	此分析检查总可用内存是否不足 - 可用内存为 10% 时发出警告，5% 可用时为严重。检测到每小时 10 MB 的下降趋势时，也会发出警告，这可能指示潜在的内存状况即将出现。物理内存不足可能会导致特权模式 CPU 和系统延迟增加。有关详细信息，请参阅本主题中的可用 MemoryAnalysis。
内存：释放系统页表条目	免费系统页表条目 (PTE 的) 是系统当前未使用的页表条目数。此分析通过检查是否少于 5,000 个可用 PTE，并显示警告（如果可用 PTE 少于 10,000），来确定系统是否耗尽了 PTE。没有足够的 PTE 可能会导致系统范围的挂起。另请注意，/3GB 开关将大幅降低可用 PTE 的数量。有关详细信息，请参阅本主题中的免费系统页表条目分析。
内存：内存泄漏检测	此分析确定任何进程是否消耗大量系统内存，以及进程内存消耗量是否随时间推移而增加。只要进程将内存返回给系统，消耗大量内存的进程就没问题。在图表中查找递增趋势。长时间呈上升趋势可能表示内存泄漏。 “专用字节数”是此进程已分配的、不能与其他进程共享的内存的当前大小（以字节为单位）。此分析检查每小时 10 MB 和每小时 5 MB 的增长趋势。将此分析与 PAL 中的可用内存分析相关联。有关详细信息，请参阅本主题中的内存泄漏检测分析。
内存：处理泄漏检测	此分析会检查所有进程，以确定每个进程打开了多少句柄，并确定是否怀疑句柄泄漏。具有大量句柄和/或积极向上趋势的进程可能指示句柄泄漏，这通常会导致内存泄漏。此进程当前打开的句柄总数等于此进程中每个线程当前打开的句柄总数。参考：调试诊断工具
内存：内存页输入/秒	“Pages Input/sec”是从磁盘读取页面以解决硬页错误的速率。如果进程引用虚拟内存中不在其工作集内或物理内存的某处的页面，而必须从磁盘中检索此页面，则将发生硬页面错误。此分析检查每秒是否读取超过 10 个页面文件。
内存：内存页数/秒	此分析检查“Pages/sec”是否 (高于 1,000) 。如果内存使用率较高，则系统可能通过尝试将内存分页到磁盘来耗尽内存。 “Pages/sec”是从磁盘读取页面或将页面写入磁盘以解决硬页错误的速率。此计数器是导致系统范围内延迟的故障类型的主要指标。将此分析与 PAL 中的可用内存分析和内存泄漏检测分析相关联。如果所有这些分析同时引发警报，则可能表示系统内存不足，所涉及的可疑进程并遵循 PAL 中的内存泄漏检测分析中提到的分析步骤。有关详细信息，请参阅本主题中的内存页数/秒分析。
内存：内存系统缓存驻留字节数	“系统缓存驻留字节数”是文件系统缓存中可分页操作系统代码的大小（以字节为单位）。此值仅包含当前物理页面，不包含当前未驻留的任何虚拟内存页面。此值是“Memory\\System Code Resident Bytes”的组件，表示当前位于物理内存中的所有可分页操作系统代码。此计数器仅显示上次观察的值；该值不是平均值。此分析检查每小时 10 MB 的增长趋势。在负载下，服务器可能会使用系统缓存来缓存 I/O 活动，例如磁盘。在 PAL 中与进程 IO 数据操作/秒和进程 IO 其他操作/秒分析相关联时使用。参考：文件缓存性能和优化
内存：池非分页字节	“池非分页字节数”是非分页池的大小（以字节为单位），该池是无法写入磁盘但必须保留在物理内存中（只要已分配）的对象的系统内存区域。此分析检查系统是否接近最大池非分页内存大小。它通过考虑 /3GB、物理内存大小和 32 位/64 位来估算池大小，然后确定该值是否高于估计池大小的 60%。如果系统接近最大大小，则系统可能会遇到系统范围的挂起。 boot.ini 文件中的 /3GB 开关选项可显著减小此内存池的大小。有关详细信息，请参阅本主题中的池非分页字节分析。
内存：池分页字节数	此分析检查系统是否接近最大池分页内存大小。它通过考虑 /3GB、物理内存大小和 32 位/64 位来估算池大小，然后确定该值是否高于估计池大小的 60%。如果系统接近最大大小，则系统可能会遇到系统范围的挂起。 boot.ini 文件中的 /3GB 开关选项可显著减小此内存池的大小。有关详细信息，请参阅本主题中的池分页字节分析。
内存：进程线程计数	此分析检查所有进程，以确定进程是否具有超过 500 个线程，以及线程数是否每小时增加 50 个线程。具有大量线程和/或主动上升趋势的进程可能指示线程泄漏，这通常会导致内存泄漏或上下文切换过高。高上下文切换将导致高特权模式 CPU。
内存：进程工作集	“工作集”是此过程的工作集的当前大小（以字节为单位）。工作集是进程中线程最近触摸的内存页集。如果计算机中的可用内存高于阈值，则页面将保留在进程的工作集中，即使它们未使用。当可用内存低于阈值时，将从工作集中剪裁页面。如果需要，在离开main内存之前，它们将被软故障回复到工作集中。此分析将检查每个进程中的 10 MB 或更大增长趋势。与 PAL 中的可用内存分析相关联时使用。参考：查找和消除瓶颈
网络：网络输出队列长度分析	此分析将检查网络适配器上正在等待的线程数。如果许多线程正在等待网络适配器，则系统可能由于网络延迟或网络带宽而使网络 I/O 饱和。 “输出队列长度”是数据包) 中 (输出数据包队列的长度。如果延迟时间超过 2，则表示延迟，如果可能，应发现并消除瓶颈。网络输出队列的典型原因包括大量小型网络请求和网络延迟。
网络：网络利用率分析	“字节总数/秒”是通过每个网络适配器（包括帧字符）发送和接收字节的速率。 “网络接口\字节接收/秒”是“网络接口\字节接收/秒”和“网络接口\字节发送/秒”的总和。此计数器可帮助你了解网络适配器上的流量是否饱和，以及是否需要添加另一个网络适配器。识别问题的速度取决于你拥有的网络类型以及是否与其他应用程序共享带宽。此分析将“字节总数/秒”转换为位，并将其与网络适配器的当前带宽进行比较，以计算网络利用率。接下来，它会检查利用率是否高于 50%。参考：在 .NET Core 中使用 EventCounters 衡量性能
分页文件：分页文件使用率百分比和使用率峰值百分比	页面文件实例的使用量（以百分比为单位）。另请参阅“Process\\Page File Bytes”。此分析检查使用百分比是否大于 70%。
处理器：处理器利用率分析和进程过度使用处理器	此计数器是处理器活动的主要指示器，显示采样间隔期间观察到的平均繁忙时间百分比。它通过监视服务处于非活动状态的时间并从 100% 中减去该值来计算。此分析检查每个处理器上的利用率是否大于 60%。如果是这样，请确定它是高用户模式 CPU 还是高特权模式。如果怀疑存在高特权模式 CPU，请参阅 PAL 中的特权模式 CPU 分析。如果怀疑存在用户模式处理器瓶颈，请考虑使用进程探查器分析导致 CPU 使用率过高的函数。
处理器：处理器队列长度	此分析确定平均处理器队列长度是否超过处理器数。如果是这样，则可能表示存在处理器瓶颈。将此分析与特权模式 CPU 分析和 PAL 中的进程过度使用处理器分析相关联。有关详细信息，请参阅本主题中的处理器队列长度分析。
处理器：特权模式 CPU 分析	此计数器指示线程在特权模式下运行的时间百分比。当应用程序调用操作系统函数 (例如执行文件或网络 I/O 或分配内存) 时，这些操作系统函数以特权模式执行。此分析检查特权模式 CPU 是否占用的总 CPU 的 30% 以上。如果是这样，则 CPU 消耗可能是由处理器以外的其他瓶颈（例如网络、内存或磁盘 I/O）引起的。与“处理器：中断时间百分比”和“处理器：PAL 中的高上下文切换分析”相关使用。有关详细信息，请参阅本主题中的特权模式 CPU 分析。
处理器：中断时间	“% 中断时间”是处理器在采样间隔期间接收和维护硬件中断所花费的时间。此值是生成中断的设备（例如系统时钟、鼠标、磁盘驱动程序、数据通讯线路、网络接口卡和其他外围设备）的活动的间接指示器。这些设备完成某项任务或需要注意时，通常会中断处理器。在中断期间暂挂正常线程执行。大多数系统时钟每隔 10 毫秒就会中断处理器，从而创建中断活动的背景。此计数器的急剧增加表明存在潜在的硬件问题。此分析检查大于 30% 的“中断时间百分比”。如果发生这种情况，请考虑更新与此警报相关的硬件的设备驱动程序。参考：在 .NET Core 中使用 EventCounters 衡量性能
处理器：高上下文切换	当高优先级线程抢占当前正在运行的较低优先级线程或高优先级线程阻止时，将发生上下文切换。当许多线程共享相同的优先级级别时，可能会发生高级别的上下文切换。这通常表示过多的线程正在争用系统上的处理器。一般情况下，每个处理器的上下文切换速率小于 5,000/秒不值得担心。如果上下文切换速率超过每个处理器每秒 15,000，则存在约束。有关详细信息，请参阅本主题中的高上下文切换分析。
Microsof BizTalk Server：BizTalk 冻结业务流程	当许多长时间运行的业务流程同时运行时，内存和性能问题就可能出现。业务流程引擎通过“冻结”和“解除冻结”业务流程实例来解决这些问题。冻结是将业务流程的状态序列化到 SQL Server 数据库中的过程。解除冻结是此过程的反面：从数据库反序列化业务流程的最后一个运行状态。冻结用于通过减少必须在内存中同时实例化的业务流程数来最大程度地降低系统资源的使用。因此，去hyration 可以节省内存消耗，但执行的操作成本相对较高。此分析检查 10 个或更多个的脱水。如果是这样，BizTalk Server可能 (虚拟或物理) 内存不足，大量业务流程正在等待消息，或者冻结设置未正确设置。参考：业务流程解除冻结和解除冻结
Microsoft BizTalk Server：BizTalk 高数据库会话	此计数器有两个可能的值：正常 (0) 或超过 1 (1) 。此分析检查值 1。如果是这样，则 BizTalk 已超出允许的数据库会话数的阈值。此值由 BizTalk 主机限制设置中的“每个 CPU 的数据库连接数”值控制。 “每个 CPU 的数据库连接数”是限制开始前允许的每个 CPU) (的最大并发数据库会话数。通过使用 BizTalk:Message Agent 性能对象类别下的 Database session 性能计数器，可以监视活动数据库连接数。此参数只影响出站消息阻止功能。有关详细信息，请参阅本主题中的 BizTalk 高数据库会话分析。
Microsoft BizTalk Server：BizTalk 高数据库大小	如果发生数据库阈值中为消息计数列出的任一条件，则此计数器将设置为值 1。默认情况下，数据库限制阈值中的主机消息计数设置为 50,000，这将在以下情况下触发限制条件： - 主机实例发布到订阅主机的工作队列、状态队列和挂起队列的消息总数超过 50,000。 - 后台处理表或跟踪表中的消息数超过 500,000 条消息。如果发生这种情况，请考虑一个操作过程，以减少数据库中的消息数。例如，确保 BizTalk Server 中的SQL Server作业正常运行，并使用 BizTalk Server 管理控制台中的“组中心”页来确定消息生成是否由大量挂起的消息引起。有关详细信息，请参阅本主题中的 BizTalk 高数据库大小分析。
Microsoft BizTalk Server：BizTalk 高 In-Process 消息计数	此分析检查高 In-Process 消息计数计数器，以确定是否发生了此类限制。如果是这样，请考虑调整“每个 CPU 的进程内消息”设置。此参数只影响出站消息阻止功能。在“每个 CPU 的进程内消息数”设置中输入值 0，以根据每个 CPU 的进程内消息数禁用限制。 “每个 CPU 的进程内消息”设置的默认值为 1,000。请注意，修改此值还可能会影响消息的低延迟和/或 BizTalk 资源的效率。有关详细信息，请参阅本主题中的 BizTalk 高 In-Process 消息计数分析。
Microsoft BizTalk Server：BizTalk 高消息传递速率	此分析检查高消息传递速率计数器中的值 1。高消息传递速率可能是由于处理复杂性高、出站适配器速度缓慢或系统资源暂时不足造成的。有关详细信息，请参阅本主题中的 BizTalk 高消息传递速率分析。
Microsoft BizTalk Server：BizTalk 高消息发布速率	入站主机阻止，在 BizTalk Server 中也称为“消息发布阻止”，应用于包含将消息发布到 MessageBox 数据库的接收适配器或业务流程的主机实例。此分析检查高消息发布速率计数器中的值 1。如果发生这种情况，则数据库无法跟上将消息发布到 BizTalk MessageBox 数据库的速率。引用： - 主机限制性能计数器 - BizTalk Server如何实现主机限制 - 修改基于速率的限制设置 - 什么是主机限制？
Microsoft BizTalk Server：BizTalk 高进程内存	BizTalk 进程内存使用量限制阈值设置是在输入 1 到 100 之间的值时，与工作集大小和进程可用虚拟内存总量之和相比的已用内存百分比。在指定百分比值时，将按固定的时间间隔来重新计算进程内存阈值。此分析检查高进程内存计数器中的值 1。有关详细信息，请参阅本主题中的 BizTalk 高进程内存分析。
Microsoft BizTalk Server：BizTalk 高系统内存	如果输入了 1 到 100 之间的值，则 BizTalk 物理内存使用量限制阈值设置是与可用物理内存总量相比的内存消耗百分比。如果输入的值大于 100，此设置也可以是可用物理内存总量（以兆字节为单位）。输入值 0 可以禁用基于物理内存使用率的阻止功能。默认值为 0。有关详细信息，请参阅本主题中的 BizTalk 高系统内存分析。
Microsoft BizTalk Server：BizTalk 高线程计数	“每个 CPU 的线程数”是主机进程中线程总数，包括适配器使用的线程数。如果超过此阈值，BizTalk Server将尝试减小 EPM 线程池和消息代理线程池的大小。如果高负载可能导致创建大量线程，则在这种情况下，应启用基于线程的阻止功能。此参数同时影响入站和出站阻止功能。默认情况下，基于线程的限制处于禁用状态。有关详细信息，请参阅本主题中的 BizTalk 高线程计数分析。
Microsoft BizTalk Server：BizTalk 主机队列长度	BizTalk 主机队列长度跟踪特定主机队列中的消息总数。可以使用长度大小（例如 BizTalk：MessageBox：HostCounters：Host Queue – Length），通过显示单个主机的队列深度来更详细地查看内部排队的消息数。此计数器可用于确定特定主机是否出现瓶颈。假设每个传输都使用唯一的主机，这有助于确定潜在的传输瓶颈。此分析检查是否平均队列长度大于 1。主机队列长度是加权队列长度，通过聚合目标主机 (工作 Q、状态 Q、挂起 Q) 的所有队列的记录计数。参考：BizTalk Server 2010：BizTalk Server性能测试方法
Microsoft BizTalk Server：BizTalk 主机挂起的消息队列长度	此计数器跟踪特定主机的挂起消息总数。挂起的消息是消息或业务流程的实例，BizTalk Server由于系统或消息中的错误而停止处理。通常，根据系统问题的解决办法，由系统错误导致的挂起实例是可恢复的。而由于消息问题导致的挂起实例通常不可恢复，且消息本身必须修复并重新提交到 BizTalk Server 系统。挂起的消息队列是包含处理过程中遇到错误或失败的工作项的队列。挂起队列将一直存储这些消息，直到它们被纠正、重新处理或被删除。此分析检查是否存在任何挂起的消息。递增的趋势可能表明存在严重的处理错误。引用： - 监视BizTalk Server运行状况和性能 - Microsoft BizTalk Server疑难解答
BizTalk Server：BizTalk 空闲业务流程	当前以主机实例为宿主的空闲业务流程实例的数量。此计数器是指未取得进展但不可解除冻结的业务流程。当业务流程被阻止、等待原子事务中的接收、侦听或延迟时，可能会出现这种情况。如果大量不可解冻的业务流程累积，则 BizTalk 可能会耗尽内存。冻结是将业务流程的状态序列化到 SQL Server 数据库中的过程。解除冻结是此过程的相反过程：从数据库反序列化业务流程的上次运行状态。冻结用于通过减少必须在内存中同时实例化的业务流程数来最大程度地降低系统资源的使用。引擎通过保存状态来解除实例的冻结，并释放实例所需的内存。通过解除冻结休眠业务流程实例，引擎使大量长时间运行的业务流程能够在同一台计算机上并发运行。此分析检查每小时一个空闲业务流程的增长趋势。参考：业务流程解除冻结和解除冻结。
BizTalk Server：BizTalk 入站延迟	从消息引擎从适配器接收文档到将文档发布到 MessageBox 的平均延迟（以毫秒为单位）。降低延迟对 BizTalk 的某些用户很重要，因此跟踪文档在入站适配器中花费的时间非常重要。有关详细信息，请参阅本主题中的 BizTalk 入站延迟分析。
BizTalk Server：BizTalk 消息传递延迟	这是当前对每个消息传递批施加) 毫秒 (毫秒的延迟，如果消息传递) 受到限制，则 (适用。在限制方面，根据消息是入站还是出站，在发布或处理消息时会应用延迟。延迟期与限制条件的严重性成正比。与严重性较低的限制条件相比，严重性较高的限制条件将启动更长的限制期。随着阻止条件的变化，将根据阻止机制在特定范围内延长和缩短此延迟时间。当前延迟期通过消息传递延迟 (ms) 公开，消息发布延迟 (毫秒) 与 BizTalk：Message Agent 性能对象类别关联的性能计数器。此分析检查消息传递延迟是否超过 5 秒。长消息传递延迟可能表示由于高负载而出现严重限制。参考：BizTalk Server如何实现主机限制。
BizTalk Server：BizTalk 消息传送限制状态	BizTalk 消息传递限制状态是限制的主要指标之一。它是一个标志，指示系统是否在限制消息传递 (影响 XLANG 消息处理和出站传输) 。限制条件由计数器的数值指示。有关详细信息，请参阅本主题中的 BizTalk 消息传递限制状态分析。
BizTalk Server：BizTalk 消息发布延迟	每个符合条件的批中注入的延迟，以限制消息的发布。在限制方面，根据消息是入站还是出站，在发布或处理消息时会应用延迟。延迟期与限制条件的严重性成正比。与严重性较低的限制条件相比，严重性较高的限制条件将启动更长的限制期。随着阻止条件的变化，将根据阻止机制在特定范围内延长和缩短此延迟时间。当前延迟期通过消息传递延迟 (ms) 公开，消息发布延迟 (毫秒) 与 BizTalk：Message Agent 性能对象类别关联的性能计数器。此分析检查消息发布延迟是否超过 5 秒。长消息传递延迟可能表示由于高负载而出现严重限制。参考：BizTalk Server如何实现主机限制。
BizTalk Server：BizTalk MessageBox 数据库连接失败	此性能计数器是自主机实例启动以来尝试数据库连接失败的次数。如果托管 BizTalk 数据库的SQL Server服务由于任何原因而不可用，则数据库群集会将资源从主动计算机传输到被动计算机。在此故障转移过程中，BizTalk Server 服务实例会遇到数据库连接失败，这些实例将自动重新启动以重新连接到数据库。采用故障转移期间传输的资源后，正在运行的数据库计算机（即前面提到的被动计算机）将开始处理数据库连接。有关详细信息，请参阅本主题中的 BizTalk MessageBox 数据库连接故障分析。
BizTalk Server：BizTalk 消息传送延迟：请求响应延迟	自消息引擎从适配器接收到请求文档到将响应文档返回到适配器的平均延迟时间（以毫秒计）。请参阅本主题中显示 BizTalk 入站延迟分析中如何测量延迟的图表。假设环境延迟较低，此分析会检查 Request-Response 延迟是否大于 5 秒。这可能表示入站适配器与出站适配器之间的处理延迟。引用： - 请求/响应消息传送 - 缩放解决方案
BizTalk Server：BizTalk 消息传送发布限制状态	BizTalk 消息发布限制状态是限制的主要指标之一。它是一个标志，指示系统是否在限制消息发布 (影响 XLANG 消息处理和入站传输) 。有关详细信息，请参阅本主题中的 BizTalk 消息传送发布限制状态分析。
BizTalk Server：BizTalk 业务流程挂起/秒	挂起的消息是消息或业务流程的实例，BizTalk Server由于系统或消息中的错误而停止处理。通常，根据系统问题的解决办法，由系统错误导致的挂起实例是可恢复的。而由于消息问题导致的挂起实例通常不可恢复，且消息本身必须修复并重新提交到 BizTalk Server 系统。此分析检查是否有任何挂起的消息/业务流程。引用： - 监视BizTalk Server运行状况和性能 - Microsoft BizTalk Server疑难解答
BizTalk Server：BizTalk 业务流程已完成/秒	这是每秒完成的 BizTalk 业务流程数。这是 BizTalk 正在处理的吞吐量的良好指标。此分析仅提供统计信息。参考：缩放解决方案
BizTalk Server：放弃的 BizTalk 业务流程	自从主机实例启动以来，内存中被丢弃的业务流程实例的数量。如果引擎未能持久化某个业务流程的状态，则会将其丢弃。此分析检查是否有任何丢弃的消息。参考： BizTalk 核心引擎的 WebLog
BizTalk Server：驻留在内存中的 BizTalk 业务流程	当前以主机实例为宿主的业务流程实例的数量。此分析检查驻留在内存中的业务流程是否呈递增趋势，以及驻留在内存中的 50% 以上的业务流程是否不可解冻。有关详细信息，请参阅驻留在内存分析中的 BizTalk 业务流程。
BizTalk Server：BizTalk 出站适配器延迟	这是从适配器从消息引擎获取文档到适配器发送文档的平均延迟（以秒为单位）。请参阅本主题中显示 BizTalk 入站延迟分析中如何测量延迟的图表。假设环境延迟较低，此分析检查出站适配器的平均延迟是否超过 5 秒。这可能表示通过此主机实例中的出站适配器传输消息时出现处理延迟。如果此主机实例中存在多个出站适配器，请考虑将它们分离到自己的主机中，以确定哪个出站适配器具有较高的延迟。引用： - 请求/响应消息传送。 - BizTalk Server 2006：BizTalk Server 2006 中使用 SOAP 适配器的可伸缩性案例研究 - 识别 BizTalk 层中的瓶颈 - BizTalk Server的低延迟方案优化
BizTalk Server：BizTalk 挂起的消息	尚未确认为已发送到 MessageBox 的已接收消息数。挂起的消息是已拉入内存并传递到 XLANG 业务流程但尚未处理的消息。这种情况与数据丢失无关。将消息传送到业务流程是一个多步骤过程，只是驻留在数据库中后台处理表中的消息的实例。这些挂起的消息计为进程内消息;因此，在内存中存在大量内存可能会导致系统内存限制。调整“内部消息队列大小”设置有助于控制挂起的消息数。 In-Process 每个 CPU 的消息数设置会影响当出现大量挂起消息时，何时会调用限制。这些设置位于 BizTalk 管理控制台的“主机”属性中。此分析检查仅显示此计数器的统计信息。参考：业务流程引擎性能计数器。
BizTalk Server：BizTalk 持久性点/秒	平均每秒持久化业务流程实例的次数。业务流程引擎在不同点保存正在运行的业务流程实例的状态。如果需要解除冻结业务流程实例、从受控关闭中启动或从意外关闭中恢复，它将从最后一个持久性点运行业务流程实例。为了持久保存业务流程实例，业务流程引用的所有对象实例直接或间接 (为通过其他对象) 必须可序列化。由于消息持久性频率 (需要保留数据的次数) 增加，整体性能会降低。实际上，每个持久性点都是到数据库的往返行程，因此请尽可能通过避免或合并持久性点来降低持久性点的频率。有关持久性点何时出现的详细信息，请参阅以下参考。此分析平均每秒检查 10 个以上的持久性点。这是一个一般起点。引用： - 业务流程中的持久性 - 持久性和业务流程引擎
BizTalk Server：BizTalk 专用字节数	这是主机实例的已分配专用内存的兆字节，相当于“\Process (*) \Private Bytes”性能计数器。此分析确定任何主机实例是否消耗大量系统内存，以及主机实例的内存消耗是否随时间而增加。有关详细信息，请参阅本主题中的 BizTalk 专用字节分析。
BizTalk Server：BizTalk 后台处理表大小	MessageBox 假脱机表包含系统中 (活动或等待“垃圾回收”) 的每条消息的记录。监视此表中的行数和每秒接收的消息数，同时增加系统负载提供了一种简单的方法来找到最大可持续吞吐量。只需增加输入负载，直到 1) 后台处理表开始无限期增长，或 2) 每秒接收的消息数稳定，以先到达者为准，这是最大可持续吞吐量。总之，无论其他指标如何，此度量值都将为你提供一种快速简单的方法来评估系统是否被过度驱动。当 BizTalk 后台处理表大小呈递增趋势时，由于消息传递速率 (输入速率不平衡而导致的限制会超过输出速率) 或数据库大小导致的限制。此分析检查 BizTalk 后台处理表大小是否有增加的趋势。引用： - 了解 BizTalk Server 2004 SP1 吞吐量和容量 - 可持续负载测试 - 测试引擎性能时的建议。
BizTalk Server：BizTalk 跟踪数据大小	随着BizTalk Server处理系统上越来越多的数据，BizTalk 跟踪数据库 (BizTalkDTADb) 继续增加。不受控制的增长将会降低系统性能，并可能导致跟踪数据传送服务 (TDDS) 出错。除了一般的跟踪数据之外，跟踪的消息也会在 MessageBox 数据库中累积，导致磁盘性能下降。此分析检查跟踪数据大小中每小时超过 5 MB 的增长趋势。参考：存档和清除 BizTalk 跟踪数据库
BizTalk Server：BizTalk 事务性作用域中止	这是自主机实例启动以来已中止的长时间运行或原子范围的数量。事务范围中止是在业务流程中的事务范围内发生的失败。请务必了解，仅当作用域成功完成时，才会调用范围的补偿处理程序，但随后需要撤消，因为周围范围已决定中止 (，因为该过程) 的稍后可能发生的故障。此外，在事务中止的情况下，不会发生状态的“自动”回滚。可以通过异常和补偿处理程序以编程方式实现此结果。通常不应在生产环境中发生事务性范围中止;因此，此分析会检查中止的任何事务作用域的发生情况。参考：事务
BizTalk Server：已补偿的 BizTalk 事务性范围	补偿可以视为已成功提交以响应某些错误条件的工作的逻辑撤消。请务必了解，仅当作用域成功完成时，才会调用范围的补偿处理程序，但随后需要撤消，因为周围范围已决定中止 (，因为该过程) 的稍后可能发生的故障。此外，在事务中止的情况下，不会发生状态的“自动”回滚。这种回滚可以通过编写异常处理程序和补偿处理程序来实现。通常不应在生产环境中发生事务范围补偿;因此，此分析会检查中止的任何事务作用域的发生情况。参考：事务
BizTalk Server：BizTalk 虚拟字节数	这是为主机实例的虚拟内存保留的兆字节。此分析确定任何主机实例是否消耗大量系统内存，以及主机实例的内存消耗是否随时间而增加。有关详细信息，请参阅本主题中的 BizTalk 虚拟字节分析。
BizTalk Server：BizTalk 消息代理数据库会话限制	这是与 MessageBox 各自的 BizTalk 限制设置相比的打开数据库连接数。 “每个 CPU 的数据库连接数”是限制开始前允许的每个 CPU) (的最大并发数据库会话数。有关详细信息，请参阅本主题中的 BizTalk 消息代理数据库会话限制分析。
BizTalk Server：BizTalk 消息代理数据库会话限制阈值	这是 MessageBox 的打开数据库连接数的当前阈值。 “每个 CPU 的数据库连接数”是限制开始前允许的每个 CPU) (的最大并发数据库会话数。有关详细信息，请参阅本主题中的 BizTalk 消息代理数据库会话限制阈值分析。
BizTalk Server：BizTalk 消息代理进程内消息计数限制	这是服务类正在处理的并发消息数。主机限制设置中的“每个 CPU 进程内消息数”设置是传递到终结点管理器 (EPM) 或 XLANG 尚未处理的最大消息数。有关详细信息，请参阅本主题中的 BizTalk 消息代理进程内消息计数限制分析。
BizTalk Server：BizTalk 消息代理进程内消息计数限制阈值	这是服务类正在处理的并发消息数的当前阈值。主机限制设置中的“每个 CPU 进程内消息数”设置是传递到终结点管理器 (EPM) 或 XLANG 尚未处理的最大消息数。有关详细信息，请参阅本主题中的 BizTalk 消息代理进程内消息计数限制阈值分析。
BizTalk Server：BizTalk 消息代理处理内存使用率 (MB) 限制	这是当前进程的内存使用情况 (MB) 。如果要发布的批处理具有陡峭的内存要求，或者如果处理消息的线程过多，则会发生 BizTalk 进程内存限制。有关详细信息，请参阅本主题中的 BizTalk 消息代理进程内存使用率 (MB) 限制分析。
BizTalk Server：BizTalk 消息代理进程内存使用率 (MB) 限制阈值	这是当前进程的内存使用量的当前阈值， (MB) 。可以根据此进程的实际可用内存量及其内存消耗模式动态调整阈值。如果要发布的批处理具有陡峭的内存要求，或者如果处理消息的线程过多，则会发生 BizTalk 进程内存限制。有关详细信息，请参阅本主题中的 BizTalk 消息代理进程内存使用率 (MB) 限制阈值分析。
BizTalk Server：BizTalk 消息代理线程计数限制	BizTalk 进程中的线程总数。 “每个 CPU 的线程数”是主机进程中的线程总数，包括适配器使用的线程数。如果超过此阈值，则 BizTalk Server 将尝试减小 EPM 线程池和消息代理线程池的大小。如果高负载可能导致创建大量线程，则在这种情况下，应启用基于线程的阻止功能。此参数同时影响入站和出站阻止功能。默认情况下，基于线程的限制处于禁用状态。此分析检查 BizTalk 线程计数是否大于指示可能存在限制条件的限制阈值的 80%。引用： - 主机限制性能计数器 - BizTalk Server如何实现主机限制 - 如何修改默认主机限制设置 - 影响适配器性能的配置参数 - 线程、数据库会话和限制
BizTalk Server：BizTalk 消息代理线程计数限制阈值	这是进程中线程总数的当前阈值。 “每个 CPU 的线程数”是主机进程中的线程总数，包括适配器使用的线程数。如果超过此阈值，则 BizTalk Server 将尝试减小 EPM 线程池和消息代理线程池的大小。在高负载可能导致创建大量线程的情况下，应启用基于线程的限制。此参数同时影响入站和出站阻止功能。此分析检查此限制设置是否设置为非默认值。默认情况下，基于线程的限制处于禁用状态。引用： - 主机限制性能计数器 - BizTalk Server如何实现主机限制 - 如何修改默认主机限制设置 - 影响适配器性能的配置参数 - 线程、数据库会话和限制

逻辑/物理磁盘读取/写入延迟分析

Windows 检测磁盘性能瓶颈的最可靠方法是测量磁盘的响应时间。如果响应时间大于 0.025 () 25 毫秒（这是保守的阈值），则可能会出现影响用户的明显速度缓慢和性能问题。

磁盘延迟不佳的常见原因包括磁盘碎片、性能缓存、过度饱和 SAN 以及磁盘上的负载过多。使用 SPA 工具帮助识别使用磁盘的顶级文件和进程。此外，检查“处理 IO 数据操作/秒”和“处理 IO 其他操作/秒”，以查看哪些进程消耗的磁盘 I/O 最多。请记住，性能监视器计数器无法指定涉及哪些文件。

参考

逻辑磁盘传输/秒

“磁盘传输/秒”是磁盘上的读取和写入操作速率。虽然磁盘传输与磁盘 I/O 不直接相关，但它们确实告诉我们发生了多少个磁盘操作。如果求出顺序 I/O 和随机 I/O 的平均值，则最终以每秒大约 80 个 I/O 作为一般经验法则。因此，在负载不足时，应该预期 SAN 驱动器每秒执行 80 个以上的 I/O。此分析的阈值检查查看任何逻辑磁盘是否显示不良的响应时间 (超过 25 毫秒的 I/O 操作) 。如果为 true，则每秒的磁盘传输应为或高于 80。如果没有，则需要调查磁盘体系结构。磁盘 I/O 不佳的最常见原因是逻辑单元数 (SAN 上的 LUN) 重载，这意味着多个 LUN 使用小型物理磁盘阵列的情况。

可用内存分析

“可用 Mbytes”是计算机上运行的进程可用的物理内存量（以 MB 为单位）。虚拟内存管理器会不断调整物理内存和磁盘中使用的空间，以保持操作系统和进程的最小可用字节数。当可用字节充足时，虚拟内存管理器允许进程的工作集增长，或者通过删除添加的每个新页面的旧页来保持它们稳定。当可用字节数较少时，虚拟内存管理器必须剪裁进程的工作集，以保持所需的最小值。

此分析检查总可用内存是否不足 - 10% 可用时警告，5% 可用时为严重。当检测到每小时 10 MB 的递减趋势时，也会发出警告，指示可能即将出现内存状况。物理内存不足可能会导致特权模式 CPU 和系统延迟增加。

参考

排除 Memory-Bound 问题

内存泄漏检测分析

此分析确定任何进程是否消耗大量系统内存，以及进程内存消耗量是否随时间推移而增加。只要进程将内存返回给系统，消耗大量内存的进程就没问题。在图表中查找递增趋势。长时间呈上升趋势可能表示内存泄漏。专用字节是此进程已分配的、不能与其他进程共享的内存的当前大小（以字节为单位）。此分析检查每小时 10 MB 和每小时 5 MB 的增长趋势。将此分析与可用内存分析相关联。

此外，请记住，当新启动的进程只是正常的启动行为时，最初会显示为内存泄漏。当进程继续消耗内存并且长时间不释放内存时，会发生内存泄漏。

如果怀疑存在内存泄漏情况，请安装并使用调试诊断工具。有关调试诊断工具的详细信息，请参阅参考部分。

参考

调试诊断工具

内存页数/秒分析

此分析检查“Pages/sec”是否很高。如果内存使用率较高，则系统可能通过尝试将内存分页到磁盘来耗尽内存。 “Pages/sec”是从磁盘读取页面或将页面写入磁盘以解决硬页错误的速率。此计数器是导致系统范围延迟的错误种类的主要指示器。它是“Memory\Pages Input/sec”和“Memory\Pages Output/sec”的总和。它以页数计算，因此可以与其他页计数（例如“Memory\Page Faults/sec”）进行比较。

此计数器应始终低于 1,000。此分析检查值是否高于 1,000。将此分析与可用内存分析和内存泄漏检测分析相关联。如果所有分析同时引发警报，这可能表示系统内存不足。按照本主题中有关内存泄漏检测分析的其他信息中所述的分析步骤进行操作。

参考

排除 Memory-Bound 问题

内存系统缓存驻留字节分析

“系统缓存驻留字节数”是文件系统缓存中可分页操作系统代码的大小（以字节为单位）。此值仅包含当前物理页面，不包含当前未驻留的任何虚拟内存页面。它等于任务管理器中显示的系统缓存值。因此，此值可能小于文件系统缓存使用的实际虚拟内存量。此值是“Memory\\System Code Resident Bytes”的组件，它表示当前位于物理内存中的所有可分页操作系统代码。此计数器仅显示上次观察的值；该值不是平均值。

此分析检查每小时 10 MB 的增长趋势。在负载下，服务器可能会使用系统缓存来缓存 I/O 活动，例如磁盘。与进程 IO 数据操作/秒和进程 IO 其他操作/秒分析相关联时使用。

处理器利用率分析和进程过度使用处理器

“% 处理器时间”是处理器执行非空闲线程所花费的已用时间的百分比。它是通过测量空闲线程在采样间隔内处于活动状态的持续时间，然后从间隔持续时间中减去该时间来计算的。 (每个处理器都有一个空闲线程，该线程在没有其他线程准备好运行时使用周期。) 此计数器是处理器活动的主要指示器，并显示采样间隔期间观察到的平均繁忙时间百分比。它是通过监视服务处于非活动状态的时间，并从 100% 中减去该值来计算的。

此分析检查每个处理器的利用率是否大于 60%。如果是这样，请确定是高用户模式 CPU 还是高特权模式。如果怀疑存在高特权模式 CPU，请参阅“特权模式 CPU 分析”。如果怀疑存在用户模式处理器瓶颈，请考虑使用进程探查器分析导致 CPU 使用率过高的函数。有关详细信息，请参阅参考部分中的“如何：识别导致生产环境中服务器应用程序出现高用户模式 CPU 瓶颈的函数” 一文。

处理器队列长度分析

“处理器队列长度”是处理器队列中的线程数。与磁盘计数器不同的是，此计数器只显示就绪线程，不显示正在运行的线程。即使在有多个处理器的计算机上，处理器时间也只有单个队列。因此，如果计算机具有多个处理器，需要用此值除以处理工作流的处理器数。长时间每处理器少于 10 个线程的处理器队列不管工作负载如何通常都是可接受的。

此分析确定平均处理器队列长度是否超过处理器数。如果是这样，则这可能表示处理器瓶颈。将此分析与特权模式 CPU 分析和进程过度使用处理器相关联。处理器队列是线程的集合，这些线程已准备就绪，但处理器无法执行，因为另一个活动线程当前正在执行。线程数超过处理器数的持续或重复队列表明存在处理器瓶颈。

可以将此计数器与“Processor\% Processor Time”计数器结合使用，以确定应用程序是否可以从更多 CPU 中受益。即使在多处理器计算机上，也有一个处理器时间队列。因此，在多处理器计算机中，将“处理器队列长度” (PQL) 值除以为工作负荷提供服务的处理器数

如果 CPU 非常繁忙， (90% 且利用率) 更高，并且 PQL 平均值一直高于处理器数，则可能存在可能受益于其他 CPU 的处理器瓶颈。或者，可以在应用程序级别减少线程数和队列数。这将减少上下文切换，这有利于降低 CPU 负载。 PQL 高且 CPU 利用率低的常见原因是处理器时间请求随机到达，而线程需要处理器的不规则时间量。这意味着处理器不是瓶颈。相反，需要改进的线程逻辑。

如果怀疑存在用户模式处理器瓶颈，请考虑使用进程探查器分析导致 CPU 使用率过高的函数。有关详细信息，请参阅参考部分中的“如何：识别导致生产环境中服务器应用程序出现高用户模式 CPU 瓶颈的函数”一文。

特权模式 CPU 分析

此计数器指示线程在特权模式下运行的时间百分比。当应用程序调用操作系统函数 (例如执行文件或网络 I/O 或分配内存) 时，这些操作系统函数以特权模式执行。

高特权模式 CPU 表示计算机在系统 I/O 方面花费的时间过多，而实际 (用户模式) 工作。 “% Privileged Time”是进程线程在特权模式下执行代码所花费的已用时间的百分比。调用 Windows 系统服务时，该服务通常会以特权模式运行，以获取对系统专用数据的访问权限。在用户模式下执行的线程保护此类数据，防止其访问。对系统的调用可以是直接的或间接的，例如页面错误或间隔。与某些早期操作系统不同，Windows 除了对用户和特权模式的传统保护外，还使用进程边界进行子系统保护。 Windows 代表应用程序完成的一些工作可能会出现在其他子系统进程中，以及进程中的特权时间。

此分析检查特权模式 CPU 是否占用的总 CPU 的 30% 以上。如果是这样，则 CPU 消耗可能是由处理器以外的其他瓶颈（例如网络、内存或磁盘 I/O）引起的。与百分比中断时间和高上下文切换分析相关时使用。

高上下文切换分析

当高优先级线程抢占当前正在运行的较低优先级线程或高优先级线程阻止时，会发生上下文切换。当许多线程共享同一优先级级别时，可能会发生高级别的上下文切换。这通常表明太多线程在争用系统上的处理器。如果看不到太多处理器利用率，并且看到非常低的上下文切换级别，则可能表示线程被阻止。

仅当特权模式 CPU 和整体 CPU 较高时，才应调查高上下文切换。一般情况下，每个处理器每秒小于 5,000 的上下文切换速率不值得担心。如果每个处理器的上下文切换速率超过每秒 15,000，则存在约束。

此分析检查高 CPU、高特权模式 CPU 和高 (大于 5,000 个/处理器) 每秒系统上下文切换都同时发生。如果发生高上下文切换，则减少系统上运行的线程和进程数。

BizTalk 高数据库会话分析

此计数器有两个可能的值，即正常 (0) 或超过 (1) 。此分析检查值 1。如果是这样，则 BizTalk 已超出允许的数据库会话数的阈值。此值由 BizTalk 主机限制设置中的“每个 CPU 的数据库连接数”值控制。

“每个 CPU 的数据库连接数”是限制开始前允许的每个 CPU) (的最大并发数据库会话数。此计数不包括通用的每主机会话池中的空闲数据库会话数，并且只对主机实例实际使用的会话数进行此检查。默认情况下，此选项处于禁用状态;通常，仅当数据库服务器是瓶颈或BizTalk Server系统中的低端数据库服务器时，才应启用此设置。可以使用 BizTalk：Message 代理性能对象类别下的数据库会话性能计数器监视活动数据库连接数。此参数只影响出站消息阻止功能。输入值 0 可以禁用基于数据库会话数的阻止功能。默认值为 0。

注意

“MaxWorkerThreads”注册表项会影响 BizTalk 可用的线程数，如果大多数 BizTalk 线程忙于数据库连接，可能会有所帮助。

参考

BizTalk 高数据库大小分析

此计数器是指此进程已发布的数据库队列中的消息数。此值按所有主机队列表中的项数以及后台处理表和跟踪表中的项数来衡量。队列包括工作队列、状态队列和挂起的队列。如果要将某一进程发布到多个队列，则此计数器将反映所有队列的加权平均值。

如果重新启动该主机，则内存中保留的统计信息将丢失。由于涉及一些开销，BizTalk Server仅在至少有 100 个发布（占重新启动的主机进程中发布总数的 5%）时才恢复收集统计信息。

如果发生数据库阈值中为消息计数列出的任一条件，则此计数器将设置为值 1。下面引用的主题 How to Modify the Default Host Throttling Settings（如何修改默认主机限制设置）中介绍了此阈值。默认情况下，数据库限制阈值中的主机消息计数设置为 50,000，这将在以下情况下触发限制条件：

主机实例发布到订阅主机的工作、状态和已挂起队列的消息总数超过 50,000。
后台处理表或跟踪表中的消息数超过 500,000。

由于暂停的消息包含在数据库计算的消息计数中，因此即使 BizTalk 服务器遇到低负载或无负载，也会限制消息发布。

此分析检查值 1。如果发生这种情况，请考虑一个操作过程，以减少数据库中的消息数。例如，确保 BizTalk SQL Server作业正常运行，并使用 BizTalk 管理控制台中的组中心来确定消息生成是否由大量挂起的消息引起。

参考

BizTalk 高 In-Process 消息计数分析

主机限制设置中的“每个 CPU 进程内消息数”设置是传递到终结点管理器 (EPM) 或 XLANG 未处理的最大消息数。此数字不包括从数据库检索但仍在内存中队列中等待传递的消息。可以使用 BizTalk：Message 代理性能对象类别下的进程内消息计数性能计数器来监视进程内消息数。此参数在考虑限制条件时为限制机制提供提示。实际阈值可能会自我优化。可以通过监视进程内消息计数性能计数器来验证实际阈值。

对于大型消息方案，可以将此参数设置为较小的值，其中平均消息大小较高，或者处理消息可能需要大量消息。如果方案过于频繁地遇到基于内存的限制，并且内存阈值自动调整为一个大大较低的值，则这一点显而易见。这样将指示出站传输应降低同时处理的消息数以避免占用过高内存。此外，如果适配器一次处理多个消息（例如在向限制并行连接数的服务器发送消息时）可获得更高效率，则可以将此参数优化为低于默认值的值。

此分析检查高 In-Process 消息计数计数器，以确定是否发生了此类限制。如果是这样，请考虑调整“每个 CPU 的进程内消息”设置。此参数只影响出站消息阻止功能。在“每个 CPU 的进程内消息数”设置中输入值 0，以根据每个 CPU 的进程内消息数禁用限制。 “每个 CPU 的进程内消息”设置的默认值为 1,000。请注意，修改此值还可能会影响消息的低延迟和/或 BizTalk 资源的效率。

参考

BizTalk 高消息传递速率分析

对于) 消息传递的出站 (，如果主机实例的消息传送传入速率超过消息传递传出速率 * 指定的速率) 值 (%，则BizTalk Server会限制消息的传递。可以在“消息处理限制设置”对话框中配置速率超速因子 (%) 参数。出站消息的基于速率的限制主要通过在从内存中队列中删除消息并将消息传送到终结点管理器 (EPM) 或业务流程引擎进行处理之前引入延迟来实现。不采取其他任何操作来完成出站消息的基于速率的限制。

出站阻止可能导致消息送达延迟，消息可能会在内存中队列中堆积，并可能导致出列线程被阻止，直到阻止条件得以缓解。当取消队列线程被阻止时，不会将其他消息从 MessageBox 拉取到内存中队列进行出站传递。

此分析检查高消息传递速率计数器中的值 1。高消息传递速率可能是由于处理复杂性高、出站适配器速度缓慢或系统资源暂时不足造成的。

参考

BizTalk 高进程内存分析

BizTalk 进程内存使用量限制阈值设置是在输入 1 到 100 之间的值时，与工作集大小和进程可用虚拟内存总量之和相比的已用内存百分比。默认情况下，BizTalk 进程内存使用量限制设置为 25。在指定百分比值时，将按固定的时间间隔来重新计算进程内存阈值。如果用户指定百分比值，则会根据要提交的可用内存和当前的进程内存使用情况来计算该值。

此分析检查高进程内存计数器中的值 1。如果发生这种情况，请尝试使用调试诊断来确定内存增加的原因， (查看内存泄漏检测分析) 中的引用。请注意，进程在启动期间消耗大量内存是否正常，这最初可能显示为内存泄漏，但当进程无法释放它不再需要的内存时，会发生真正的内存泄漏，从而减少了一段时间的可用内存量。有关如何在 BizTalk 中一般分析进程内存泄漏的详细信息，请参阅下面的“如何捕获正在泄漏内存的进程内存转储”参考和/或 PAL 中的“内存泄漏检测”分析。

如果要发布的批处理的内存要求过高，或者处理消息的线程过多，则可能会发生高进程内存限制。如果系统似乎超出限制，请考虑增加与主机的进程内存使用阈值关联的值，并验证主机实例是否未生成“内存不足”错误。如果通过提高进程内存使用阈值引发“内存不足”错误，请考虑减小每个 CPU 阈值的内部消息队列大小和进程内消息的值。此策略特别适用于大型消息处理方案。此外，对于每条消息内存需求较大的方案，此值应设置为低值。设置较低的值会在早期启动限制，并防止进程内的内存爆炸。

如果 BizTalk 服务器经常耗尽虚拟内存，请考虑BizTalk Server 64 位。 64 位服务器上的每个进程最多可以处理 4 TB 的虚拟内存，而 32 位中为 2 GB 的虚拟内存。通常，强烈建议使用 64 位 BizTalk 和 64 位SQL Server。有关详细信息，请参阅“BizTalk Server 64 位支持”参考。

参考

BizTalk 高系统内存分析

如果输入了 1 到 100 之间的值，则 BizTalk 物理内存使用量限制阈值设置是与可用物理内存总量相比的内存消耗百分比。如果输入的值大于 100，此设置也可以是可用物理内存总量（以兆字节为单位）。输入值 0 可以禁用基于物理内存使用率的阻止功能。默认值为 0。

此分析检查高系统内存计数器中的值 1。由于这样将度量系统内存总量，因此如果非 BizTalk Server 进程占用过多的系统内存，则可能会触发阻止条件。因此，如果发生这种情况，最佳方法是确定哪些进程消耗了最多的物理内存和/或向服务器添加额外的物理内存。此外，请考虑通过减少 EPM 线程池的默认大小和/或适配器批的大小来减少负载。有关详细信息，请参阅 PAL 中的内存泄漏检测分析。

参考

BizTalk 高线程计数分析

“每个 CPU 的线程数”是主机进程中线程总数，包括适配器使用的线程数。如果超过此阈值，BizTalk Server将尝试减小 EPM 线程池和消息代理线程池的大小。如果高负载可能导致创建大量线程，则在这种情况下，应启用基于线程的阻止功能。此参数同时影响入站和出站阻止功能。默认情况下，基于线程的限制处于禁用状态。

注意

用户指定的值用作准则，主机可以根据进程的内存使用模式和线程要求动态自行调整此阈值。

此分析检查高线程计数计数器中的值 1。考虑调整不同线程池的大小，以确保系统不会创建大量线程。此分析可以与每秒上下文切换分析相关联，以确定操作系统是否饱和了过多的线程，但在大多数情况下，高线程计数会导致后端数据库上的争用比 BizTalk 服务器上更多。有关修改线程池大小的详细信息，请参阅如何修改引用中的默认主机限制设置。

参考

主机限制性能计数器
BizTalk Server 如何实现主机限制
如何修改默认主机限制设置
影响适配器性能的配置参数
线程、数据库会话和限制

BizTalk 入站延迟分析从消息引擎从适配器接收文档到将文档发布到消息框为止的延迟（以毫秒为单位）。降低延迟对 BizTalk 的某些用户很重要，因此跟踪文档在入站适配器中花费的时间非常重要。

下面是显示如何测量延迟的图表。

1	2	3	4	5	6
适配器接收消息并将其提交到引擎，在将消息提供给未在这些性能计数器中捕获的引擎之前，在适配器中完成工作	引擎从适配器接收消息，执行接收管道、映射、订阅评估、在 DB 中保存消息。	业务流程或 Solicit-Response 端口运行并生成响应消息。	响应消息在消息引擎中取消排队，执行发送管道，映射。	消息引擎向适配器提供响应消息。	适配器通知引擎消息已完成。
	I
	Rr	Rr	Rr
			O	O	O
				OA	OA

I = 入站延迟

RR = 请求响应延迟

O = 出站延迟

OA = 出站适配器延迟

假设环境延迟较低，此分析会检查文档是否在入站适配器中花费了 5 秒以上。这可能表示通过此主机实例中的入站适配器传输消息时出现处理延迟。如果此主机实例中存在多个入站适配器，请考虑将它们分离到自己的主机中，以确定哪个入站适配器具有较高的延迟。

参考

BizTalk 消息传递限制状态分析

BizTalk 消息传递限制状态是限制的主要指标之一。它是一个标志，指示系统是否在限制消息传递 (影响 XLANG 消息处理和出站传输) 。限制条件由计数器的数值指示。下面是值及其各自含义的列表：

限制条件	说明
0	非限制
1	由于消息送达速率不匹配（输入速率超出输出速率）而阻止
3	由于进程内消息数过高而阻止
4	由于进程内存压力而阻止
5	由于系统内存压力而阻止
9	由于线程数过高而阻止
10	由于送达时的用户替代而阻止

此分析检查其中每个值，并为每个值提供特定的警报。

参考

BizTalk MessageBox 数据库连接故障分析

此性能计数器是自主机实例启动以来尝试数据库连接失败的次数。如果托管 BizTalk 数据库的SQL Server服务由于任何原因而不可用，则数据库群集会将资源从主动计算机传输到被动计算机。在此故障转移过程中，BizTalk Server 服务实例会遇到数据库连接失败，这些实例将自动重新启动以重新连接到数据库。采用故障转移期间传输的资源后，正在运行的数据库计算机（即前面提到的被动计算机）将开始处理数据库连接。

DBNetLib (数据库网络库) 错误发生时，BizTalk Server运行时无法与 MessageBox 或管理数据库通信。发生这种情况时，捕获异常的BizTalk Server运行时实例会关闭，然后每隔一分钟循环一次，检查以查看数据库是否可用。有关本主题的详细信息，请参阅参考部分。

当客户端启动到服务器的 TCP/IP 套接字连接时，客户端通常连接到服务器上的特定端口，并请求服务器通过临时（或暂时）TCP 或 UDP 端口进行响应。在 Windows Server 2003 和 Windows XP 上，客户端应用程序使用的临时端口的默认范围为 1025 到 5000。在某些情况下，默认范围内的可用端口可能会耗尽。有关本主题的详细信息，请参阅参考部分。

此分析检查是否存在数据库连接失败的情况。数据库连接失败至关重要，因为没有数据库，BizTalk 无法正常工作。如果数据库连接失败的原因未知，请考虑下面列出的引用和/或联系Microsoft 支持部门以确定连接失败的性质。

参考

BizTalk 消息传送发布限制状态分析

BizTalk 消息发布限制状态是限制的主要指标之一。它是一个标志，指示系统是否在限制消息发布 (影响 XLANG 消息处理和入站传输) 。限制条件由计数器的数值指示。下面是值及其各自含义的列表：

限制条件	说明
0	非限制
2	由于消息发布速率不匹配（输入速率超出输出速率）而阻止
4	由于进程内存压力而阻止
5	由于系统内存压力而阻止
6	由于数据库增长而阻止
8	由于会话数过高而阻止
9	由于线程数过高而阻止
11	由于发布时的用户替代而阻止

此分析检查其中每个值，并为每个值提供特定的警报。

参考

驻留在内存中的 BizTalk 业务流程

当前以主机实例为宿主的业务流程实例的数量。虽然驻留在内存中的业务流程的峰值或突发可能被视为正常，但增加的趋势可能表明内存中业务流程“堆积如山”。当 BizTalk 无法解除消息/业务流程实例的冻结时，可能会随着时间推移而呈上升趋势。尝试将此计数器与“XLANG/s Orchestrations (？) \Dehydratable orchestrations”相关联，其中问号 (？) 与此计数器是同一计数器实例。

如果大量业务流程驻留在内存中，并且少量业务流程可解除冻结，则业务流程可能在内存中处于空闲状态，并可能导致内存泄漏情况。将此分析与“\XLANG/s 业务流程 (*) \空闲业务流程”（如果存在）相关联。由于无法解除业务流程实例的冻结，BizTalk 空闲业务流程中的上升趋势是内存泄漏的更好指标。

此分析检查驻留在内存中的业务流程是否呈上升趋势，以及驻留在内存中的业务流程是否超过 50% 不可解冻。

参考

BizTalk 专用字节分析

这是主机实例的已分配专用内存的兆字节，相当于“\Process (*) \Private Bytes”性能计数器。专用字节是进程分配的内存的当前大小（以字节为单位），不能与其他进程共享。此分析确定任何主机实例是否消耗大量系统内存，以及主机实例的内存消耗是否随时间而增加。只要主机实例将内存返回给系统，消耗大量内存的主机实例就没问题。在图表中查找递增趋势。长时间呈上升趋势可能表示内存泄漏。

此分析检查每小时 10 MB 的增长趋势。将此分析与可用内存分析和内存泄漏分析相关联。此外，请记住，当新启动的主机实例只是正常的启动行为时，最初会显示为内存泄漏。内存泄漏是进程继续消耗内存且长时间不释放内存时。如果怀疑存在内存泄漏情况，请阅读下面引用的“BizTalk 消息传送中的内存增长”一文。否则，请安装并使用调试诊断工具。有关调试诊断工具的详细信息，请参阅参考部分。

参考

BizTalk 虚拟字节分析

这是为主机实例保留的虚拟内存的兆字节。此分析确定任何主机实例是否消耗大量系统内存，以及主机实例的内存消耗是否随时间推移而增加。只要主机实例将内存返回给系统，消耗大量内存就没问题。在图表中查找递增趋势。长时间呈上升趋势可能表示内存泄漏。

此分析检查虚拟字节数每小时 10 MB 的增长趋势。将此分析与可用内存分析和内存泄漏分析相关联。此外，请记住，当新启动的主机实例只是正常的启动行为时，最初会显示为内存泄漏。内存泄漏是进程继续消耗内存且长时间不释放内存时。如果怀疑存在内存泄漏情况，请阅读下面的“BizTalk 消息传送中的内存增长”一文。否则，请安装并使用调试诊断工具。有关调试诊断工具的详细信息，请参阅参考部分。

参考

BizTalk 消息代理数据库会话限制分析

这是与其各自的 BizTalk 限制设置相比，MessageBox 打开的数据库连接数。 “每个 CPU 的数据库连接数”是限制开始前允许的每个 CPU) (的最大并发数据库会话数。此计数不包括通用的每主机会话池中的空闲数据库会话数，并且只对主机实例实际使用的会话数进行此检查。默认情况下，此选项为禁用状态；通常，只有当数据库服务器成为 BizTalk Server 系统的瓶颈时才应启用此设置。可以使用 BizTalk：Message 代理性能对象类别下的数据库会话性能计数器监视活动数据库连接数。此参数只影响出站消息阻止功能。输入值 0 可以禁用基于数据库会话数的阻止功能。默认值为 0。

MaxWorkerThreads 注册表项会影响 BizTalk 可用的线程数，在 BizTalk 的大多数线程忙于数据库连接的情况下可能会有所帮助。此分析检查 MessageBox 的打开数据库连接数是否大于数据库会话限制设置的 80%，指示可能存在限制条件。

参考

BizTalk 消息代理数据库会话限制阈值分析

这是对 MessageBox 打开数据库连接数的当前阈值。 “每个 CPU 的数据库连接数”是限制开始前允许的每个 CPU) (的最大并发数据库会话数。此计数不包括通用的每主机会话池中的空闲数据库会话数，并且只对主机实例实际使用的会话数进行此检查。默认情况下，此选项为禁用状态；通常，只有当数据库服务器成为 BizTalk Server 系统的瓶颈时才应启用此设置。可以使用 BizTalk：Message 代理性能对象类别下的数据库会话性能计数器监视活动数据库连接数。此参数只影响出站消息阻止功能。输入值 0 可以禁用基于数据库会话数的阻止功能。默认值为 0。

MaxWorkerThreads 注册表项会影响 BizTalk 可用的线程数，在 BizTalk 的大多数线程忙于数据库连接的情况下可能会有所帮助。此分析检查此值，以查看它是否已从其默认设置修改。默认情况下，此设置为 0，这意味着对数据库会话的限制处于禁用状态。

参考

BizTalk 消息代理进程内消息计数限制分析

这是服务类正在处理的并发消息数。主机限制设置中的“每个 CPU 进程内消息数”设置是传递到终结点管理器 (EPM) 或 XLANG 未处理的最大消息数。这不包括从数据库检索到的消息，但仍在内存中队列中等待传递的消息。可以使用 BizTalk：Message Agent 性能对象类别下的进程内消息计数性能计数器监视进程内消息数。此参数提供了阻止机制提示以便您考虑阻止条件。实际阈值可能会自我优化。通过监视 In-process message count 性能计数器，可以验证实际的阈值。

对于 (平均消息大小较高或消息处理可能需要大量消息) 的大型消息方案，可以将此参数设置为较小的值。如果基于内存的限制发生频率过频繁，并且内存阈值自动调整为一个相当低的值，则会指示大型消息场景。这样将指示出站传输应降低同时处理的消息数以避免占用过高内存。此外，如果适配器一次处理多个消息（例如在向限制并行连接数的服务器发送消息时）可获得更高效率，则可以将此参数优化为低于默认值的值。此分析检查高 In-Process 消息计数计数器，以确定它是否大于其同名限制设置的 80%，这表示可能存在限制条件。

参考

BizTalk：消息代理进程内消息计数限制阈值分析

这是服务类正在处理的并发消息数的当前阈值。主机限制设置中的“每个 CPU 进程内消息数”设置是传递到终结点管理器 (EPM) 或 XLANG 未处理的最大消息数。这不包括从数据库检索到的消息，但仍在内存中队列中等待传递的消息。可以使用 BizTalk：Message Agent 性能对象类别下的进程内消息计数性能计数器监视进程内消息数。此参数提供了阻止机制提示以便您考虑阻止条件。实际阈值可能会自我优化。通过监视 In-process message count 性能计数器，可以验证实际的阈值。

参考

BizTalk 消息代理进程内存使用情况 (MB) 限制分析

这是当前进程的内存使用量 (MB) 。如果要发布的批处理的内存要求过高，或者处理消息的线程过多，则会发生 BizTalk 进程内存限制。如果系统似乎超出限制，请考虑增加与主机的进程内存使用阈值关联的值，并验证主机实例是否未生成“内存不足”错误。如果通过提高进程内存使用阈值引发“内存不足”错误，请考虑减小每个 CPU 阈值的内部消息队列大小和进程内消息的值。此策略特别适用于大型消息处理方案。

如果 BizTalk 服务器经常耗尽虚拟内存，请考虑BizTalk Server 64 位。 64 位服务器上的每个进程最多可以寻址 4 TB 的虚拟内存，而 32 位中的 2 GB 内存则为 2 TB。通常，强烈建议使用 64 位 BizTalk 和 64 位SQL Server。有关详细信息，请参阅“BizTalk Server 64 位支持”参考。此分析检查进程内存使用量是否大于其同名的相应限制阈值的 80%。默认情况下，BizTalk 进程内存使用量限制设置是进程可用虚拟内存的 25%。 /3GB 开关对此设置没有影响。

参考

BizTalk：消息代理进程内存使用情况 (MB) 限制阈值分析

这是当前进程的内存使用量的当前阈值， (MB) 。根据此进程的实际可用内存量及其内存消耗模式，可以动态调整阈值。如果要发布的批处理的内存要求过高，或者处理消息的线程过多，则会发生 BizTalk 进程内存限制。如果系统似乎超出限制，请考虑增加与主机的进程内存使用阈值关联的值，并验证主机实例是否未生成“内存不足”错误。如果通过提高进程内存使用阈值引发“内存不足”错误，请考虑减小每个 CPU 阈值的内部消息队列大小和进程内消息的值。此策略特别适用于大型消息处理方案。