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 检测磁盘性能瓶颈的最可靠方法是测量其响应时间。 如果响应时间大于 .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 和系统延迟增加。 有关详细信息，请参阅本主题中的可用内存分析。 |
| 内存：空闲系统页表条目 | 免费系统页表条目（PTE）是系统当前未使用的页表条目数。 此分析通过检查可用 PTE 是否少于 5,000 个来确定系统是否耗尽 PTE，并在可用 PTE 少于 10,000 个时发出警告。 缺乏足够的 PTE 可能会导致系统范围的挂起。 另请注意，/3GB 交换机将显著降低免费 PTE 的数量。 有关详细信息，请参阅本主题中的免费系统页表条目分析。 |
| 内存：内存泄漏检测 | 此分析确定任何进程是否消耗大量系统的内存，以及进程是否随时间而增加内存消耗。 只要进程将内存返回回系统，占用大量内存的进程就没问题。 在图表中查找增加的趋势。 增长趋势持续很长一段时间可能表明内存泄漏。 “专用字节”是此进程分配的无法与其他进程共享的内存的当前大小（以字节为单位）。 此分析检查每小时 10 MB 和每小时 5 MB 的增长趋势。 将此分析与 PAL 中的可用内存分析相关联。 有关详细信息，请参阅本主题中的内存泄漏检测分析。 |
| 内存：句柄泄漏检测 | 此分析检查所有进程，以确定每个进程打开了多少句柄，并判断是否存在句柄泄漏。 具有大量句柄和/或主动向上趋势的进程可能表示句柄泄漏，这通常会导致内存泄漏。 此进程当前打开的句柄总数等于此进程中每个线程当前打开的句柄的总和。 参考： 调试诊断工具 |
| 内存：内存页输入数/秒 | "Pages Input/sec" 是指从磁盘读取页面来处理硬性页面故障的速率。 当进程引用虚拟内存中的页面时，将发生硬页错误，该页面不在其工作集中或物理内存中的其他位置，并且必须从磁盘中检索。 此分析检查每秒页面文件读取次数是否超过10次。 |
| 内存：内存页数/秒 | 此分析检查“Pages/sec”是否高（高于 1,000）。 如果它很高，则系统可能耗尽内存，方法是尝试将内存分页到磁盘。 “Pages/sec”是指从磁盘读取或写入页面以解决硬性页错误的速率。 此计数器是导致系统范围的延迟的故障类型的主要指标。 将此分析与 PAL 中的可用内存分析和内存泄漏检测分析相关联。 如果发现所有这些分析同时引发警报，这可能表明系统内存不足，并且涉及可疑进程。请按照 PAL 中的内存泄漏检测分析中提到的分析步骤进行分析。 有关详细信息，请参阅本主题中的“内存页数/秒分析”。 |
| 内存：内存系统缓存驻留字节数 | “系统缓存驻留字节数”是文件系统缓存中可分页作系统代码的大小（以字节为单位）。 此值仅包括当前物理页，不包括当前未驻留的任何虚拟内存页。 此值是“内存\\系统代码驻留字节”的一个组件，表示当前位于物理内存中的所有可分页作系统代码。 此计数器仅显示最后一个观察到的值;它不是平均值。 该分析检查每小时增加 10 兆字节的趋势。 在负载下，服务器可能会使用系统缓存来缓存 I/O 活动，例如磁盘。 在 PAL 中，与 Process IO 数据操作/秒和 Process IO 其他操作/秒的分析结合使用。 参考： 文件缓存性能和优化 |
| 内存：池非分页字节数 | “池非分页字节”是非分页池的大小（以字节为单位），指用于无法写入磁盘的对象的系统内存区域。这些对象在被分配时必须保留在物理内存中。 本分析检查系统是否正在接近其非分页内存池的最大大小。 它通过估算考虑 /3GB、物理内存大小和 32 位/64 位的池大小，然后确定该值是否高于估计池大小的 60%。 如果系统接近最大大小，则系统可能会遇到系统范围的挂起。 boot.ini 文件中的 /3GB 开关选项会显著减小此内存池的大小。 有关详细信息，请参阅本主题中的非分页字节池分析。 |
| 内存：池分页字节数 | 此分析检查系统是否接近分页池的最大内存大小。 它通过估算池大小来考虑 /3GB、物理内存大小和 32 位/64 位，然后确定该值是否高于估计池大小的 60%。 如果系统接近最大容量，可能会发生全局挂起。 boot.ini 文件中的 /3GB 开关选项会显著减小此内存池的大小。 有关更多信息，请查阅本主题中的分页池字节分析。 |
| 内存：进程线程计数 | 此分析检查所有进程，以确定进程是否具有 500 个以上的线程，以及线程数是否每小时增加 50 个线程。 具有大量线程和/或激进向上趋势的进程可能表示线程泄漏，这通常会导致内存泄漏或上下文切换较高。 上下文切换频繁会导致 CPU 运行在高特权模式下。 |
| 内存：进程工作集 | “工作集”是此过程的工作集的当前大小（以字节为单位）。 工作集是进程内线程最近接触的内存页集。 如果计算机中的可用内存超出阈值，即使页面未使用，页面也会保留在进程的工作集中。 当可用内存低于阈值时，页面会从工作集中被减少。 如果需要，则在离开主内存之前，它们将被软故障回复到工作集中。 该分析检查每个进程中是否存在增长趋势，且增幅为10兆字节或更多。 结合 PAL 中的可用内存分析来使用。 参考： 查找和消除瓶颈 |
| 网络：网络输出队列长度分析 | 此分析检查在网络适配器上等待的线程数。 如果大量线程在网络适配器上等待，则系统可能会由于网络延迟或网络带宽而使网络 I/O 饱和。 “输出队列长度”是输出数据包队列（以数据包为单位）的长度。 如果延迟超过两个，则应找到并消除瓶颈（如果可能）。 网络输出队列的典型原因包括大量小型网络请求和网络延迟。 |
| 网络：网络利用率分析 | “Bytes Total/sec”是通过每个网络适配器（包括帧字符）发送和接收字节的速率。 “网络接口\字节接收/秒”是“网络接口\字节接收/秒”和“网络接口\字节已发送/秒”的总和。 此计数器可帮助你了解网络适配器上的流量是否饱和，以及是否需要添加另一个网络适配器。 确定问题的速度取决于你拥有的网络类型以及你是否与其他应用程序共享带宽。 此分析将“Bytes Total/sec”转换为位，并将其与网络适配器的当前带宽进行比较，以计算网络利用率。 接下来，它会检查利用率是否超过 50%。 参考： 使用 .NET Core 中的 EventCounters 测量性能 |
| 分页文件：分页文件 % 使用情况和 % 的使用高峰值 | 正在使用的页面文件实例量（以百分比为单位）。 另请参阅“Process\\Page File Bytes”。 此分析检查使用情况百分比是否大于 70%。 |
| 处理器：处理器利用率分析和进程过度使用处理器 | 此计数器是处理器活动的主要指标，并显示样本间隔期间观察到的忙碌时间的平均百分比。 它通过监视服务处于非活动状态的时间并从 100% 中减去该值来计算。 此分析检查每个处理器上的利用率是否大于 60%。 如果是这样，请确定它是高用户模式 CPU 还是高特权模式。 如果怀疑高权限模式 CPU，请参阅 PAL 中的权限模式 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 数据库的过程。 解除冻结是此过程的反转：从数据库反序列化业务流程的最后一个运行状态。 脱水用于通过减少在内存中同时实例化的编排数量来最小化系统资源的使用。 因此，去水化可节省内存消耗，但操作相对较昂贵。 此分析检查是否有 10 个或以上的脱水情况。 如果是这样，BizTalk Server 可能内存不足（虚拟或物理），大量业务流程正在等待消息，或者未正确设置冻结设置。 参考： 业务流程脱水和还原 |
| Microsoft BizTalk Server：BizTalk 高负载数据库会话 | 此计数器有两个可能的值：普通值（0）或超过（1）。 此分析检查数值是否为 1。 如果是这样，BizTalk 已超过允许的数据库会话数的阈值。 此值由 BizTalk 主机限制设置中的“每个 CPU 的数据库连接”值控制。 “每个 CPU 的数据库连接”是限制开始前允许的最大并发数据库会话数（每个 CPU）。 可以使用 BizTalk：Message 代理性能对象类别下的“数据库会话性能计数器”监视活动数据库连接数。 此参数仅影响出站消息限流。 有关详细信息，请参阅本主题中的 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 的In-Process 消息”设置。 此参数仅影响出站消息限流。 在“每个 CPUIn-Process 消息数”设置中输入值 0，以根据每个 CPU 的进程内消息数禁用限速。 “In-Process 每个 CPU 消息”设定的默认值为 1,000。 请注意，修改此值还可能会影响消息的低延迟和/或 BizTalk 资源的效率。 有关详细信息，请参阅本主题中的 BizTalk High In-Process 消息计数分析。 |
| Microsoft BizTalk Server：BizTalk 高消息传递率 | 此分析检查“高消息传递速率”计数器中的值是否为 1。 高消息传递率可能是由于处理复杂性高、出站适配器缓慢或系统资源的暂时短缺造成的。 有关详细信息，请参阅本主题中的 BizTalk 高消息传递速率分析。 |
| Microsoft BizTalk Server：BizTalk 高消息发布速率 | 入站主机限制（也称为 BizTalk Server 中的消息发布限制）应用于包含将消息发布到 MessageBox 数据库的接收适配器或业务流程的主机实例。 此分析检查 "高消息发布速率" 计数器中是否存在一个值为1。 如果发生这种情况，则数据库无法跟上将消息发布到 BizTalk MessageBox 数据库的速率。 引用： - 主机限流性能计数器 - BizTalk Server 如何实现主机限制 - 修改基于速率的限流设置 - 什么是主机限制？ |
| Microsoft BizTalk Server：BizTalk 进程内存过高 | 如果输入 1 到 100 之间的值，则 BizTalk 进程内存使用率限制阈值设置是与工作集大小和进程可用虚拟内存的总和相比使用的内存百分比。 指定百分比值时，将定期重新计算进程内存阈值。 此分析检查高进程内存计数器中是否存在值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、State Q、Suspended 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 代理性能对象类别关联的消息发布延迟（ms）性能计数器公开。 此分析检查消息传递延迟是否大于 5 秒。 由于高负载导致限速严重，消息长时间延迟传送。 参考： BizTalk Server 如何实现主机限制。 |
| BizTalk Server：BizTalk 消息传递限制状态 | BizTalk 消息传递的节流状态是节流的主要指示器之一。 它是一个标志，指示系统是否正在限制消息传递（影响 XLANG 消息处理和出站传输）。 限流条件通过计数器的数值来指示。 有关详细信息，请参阅本主题中的 BizTalk 消息传递限制状态分析。 |
| BizTalk Server：BizTalk 消息发布延迟 | 在每个符合条件的批处理中注入的延迟，以限制消息的发布。 对于限流，根据消息是入站还是出站，在发布或处理消息时可能会施加延迟。 延迟期与限速条件的严重性成正比。 较高严重性的限制条件将启动较低严重性限制条件更长的限制期。 随着条件的变化，限制机制在特定的范围内上下调整此延迟期。 当前延迟期通过消息传递延迟（ms）和与 BizTalk：Message 代理性能对象类别关联的消息发布延迟（ms）性能计数器公开。 此分析检查消息发布延迟是否大于 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 的Low-Latency 方案优化 |
| BizTalk Server：BizTalk 挂起的消息 | 接收到但尚未确认的 MessageBox 消息数量。 挂起的消息是已被拉入内存并传递到 XLANG 编排的消息，但尚未进行处理。 这种情况与数据丢失无关。 将消息传送到业务流程是一个多步骤过程，只是驻留在数据库中后台表中的消息的实例。 这些挂起的消息计为处理中消息；因此，内存中存在大量挂起消息可能会导致系统上出现内存限制问题。 调整内部消息队列大小设置有助于控制挂起的消息数。 In-Process“每个 CPU 的消息数”设置会影响当出现大量挂起消息时，何时会触发限流。 这些设置位于 BizTalk 管理控制台的主机属性中。 此分析检查仅显示此计数器的统计信息。 参考： 编排引擎性能计数器。 |
| BizTalk Server：每秒 BizTalk 持久化点 | 每秒保存的编排实例平均数量。 编排引擎在多个节点保存正在运行的编排实例的状态。 如果需要解除业务流程实例的冻结、从受控关闭启动或从意外关闭中恢复，它将从最后一个持久性点运行业务流程实例。 为了持久化编配实例，您的编配直接或间接（如通过其他对象）引用的所有对象实例必须可序列化。 随着消息持久性频率（需要持久保存数据的次数）的增加，整体性能会降低。 实际上，每个持久化点都是对数据库的一次往返，因此，尽可能减少持久化点的频率，通过避免非必要的持久化点或合并持久化点。 有关何时发生持久性点的详细信息，请参阅以下参考。 此分析检测平均每秒超过 10 个持久性点。 这是常见的起始点。 引用： - 编排中的持久性 - 持久性和编排引擎 |
| BizTalk Server：BizTalk 专用字节 | 这是主机实例分配的专用内存的兆字节，与“\Process\\Private Bytes”性能计数器相当。 此分析确定任何主机实例是否消耗了大量的系统内存，并且内存消耗是否会随着时间的推移而增加。 有关详细信息，请参阅本主题中的 BizTalk 专用字节分析。 |
| BizTalk Server：BizTalk 暂存表大小 | MessageBox 后台处理表包含系统中每条消息的记录（活动状态或等待被清理）。 监视此表中的行数和每秒接收的消息数，同时增加系统负载提供了一种简单的方法来查找最大可持续吞吐量。 只需增加输入负载，直到线轴表开始无休止地增长，或每秒接收的消息数量达到平台期，以先发生者为准，即为您的最大可持续吞吐量。 总之，无论其他指标如何，此度量都会为你提供一种快速而简单的方法来评估系统是否过度驱动。 当 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 检测磁盘性能瓶颈的最可靠方法是测量其响应时间。 如果响应时间大于 .025（25 毫秒），这是一个保守的阈值，则影响用户的明显缓慢和性能问题可能会发生。
磁盘延迟不佳的常见原因是磁盘碎片、性能缓存、过度饱和 SAN 和磁盘上的负载过多。 使用 SPA 工具帮助识别使用磁盘的顶级文件和进程。 另请查看“处理 IO 数据作数/秒”和“进程 IO 其他作数/秒”，查看哪些进程消耗了最多的磁盘 I/O。 请记住，性能监视器计数器无法指定涉及哪些文件。
参考文献
逻辑磁盘传输/秒
“磁盘传输/秒”是磁盘上的读取和写入作速率。 虽然磁盘传输与磁盘 I/O 不直接相关，但它们确实告诉我们发生了多少次磁盘操作。 如果对顺序 I/O 和随机 I/O 取平均值，那么作为一个一般性指导原则，您最终每秒会得到大约 80 个 I/O。 因此，在负载不足时，我们应期望 SAN 驱动器每秒执行 80 个以上的 I/O。 此分析阈值检查是否有逻辑磁盘显示响应时间较差（I/O操作的响应时间大于25毫秒）。 如果这是真的，则应预期每秒的磁盘传输量在 80 或更高。 如果没有，则需要调查磁盘体系结构。 磁盘 I/O 差的最常见原因是 SAN 上的逻辑单元数（LUN）重载，这意味着多个 LUN 正在使用小型物理磁盘阵列的条件。
可用内存分析
“可用兆字节”是指计算机上运行的进程可用的物理内存量，以兆字节为单位。 虚拟内存管理器不断调整物理内存和磁盘上使用的空间，以保持作系统和进程的最小可用字节数。 当可用字节充足时，虚拟内存管理器允许进程的工作集增长，或通过为每个添加的新页面删除一个旧页面来保持稳定。 如果可用字节数很少，虚拟内存管理器必须剪裁进程的工作集，以维持最低要求。
此分析检查总可用内存是否不足 – 可用内存为 10% 时触发警告，5% 时触发严重警报。 检测到每小时 10 MB 的下降趋势时，还会发出警告，指示潜在的即将发生的内存状况。 物理内存不足可能会导致特权模式 CPU 和系统延迟增加。
参考文献
内存泄漏检测分析
此分析确定任何进程是否消耗大量系统的内存，以及进程是否随时间而增加内存消耗。 只要进程将内存返回回系统，占用大量内存的进程就没问题。 在图表中查找增加的趋势。 增长趋势持续很长一段时间可能表明内存泄漏。 专用字节是此进程分配的无法与其他进程共享的内存的当前大小（以字节为单位）。 此分析检查每小时 10 MB 和每小时 5 MB 的增长趋势。 将此分析与可用内存分析相关联。
此外，请记住，当新启动的进程只是正常的启动行为时，它最初将显示为内存泄漏。 当进程继续占用内存且不会长时间释放内存时，会发生内存泄漏。
如果怀疑内存泄漏情况，请安装并使用调试 Diag 工具。 有关调试 Diag 工具的详细信息，请参阅参考部分。
参考文献
内存页数/秒分析
此分析用于检查“每秒页数”这一指标是否偏高。 如果它很高，则系统可能耗尽内存，方法是尝试将内存分页到磁盘。 “Pages/sec”是指从磁盘读取或写入页面以解决硬性页错误的速率。 此计数器是导致系统范围延迟的故障类型的主要指标。 它是“Memory\Pages Input/sec”和“Memory\Pages Output/sec”的总和。 它以页数计算，因此它可以与其他页计数（例如“内存\页面错误数/秒”）进行比较。
此计数器应始终低于 1,000。 此分析检查值是否超过 1,000。 将此分析与可用内存分析和内存泄漏检测分析相关联。 如果所有分析同时引发警报，则可能表示系统内存不足。 按照本主题中提到的有关内存泄漏检测分析的其他信息来执行分析步骤。
参考文献
内存系统缓存驻留字节分析
“系统缓存驻留字节数”是文件系统缓存中可分页作系统代码的大小（以字节为单位）。 此值仅包括当前物理页，不包括当前未驻留的任何虚拟内存页。 它与任务管理器中显示的系统缓存值相同。 因此，此值可能小于文件系统缓存使用的实际虚拟内存量。 此值是“Memory\\System Code Resident Bytes”的一个组件，表示当前位于物理内存中的所有可分页作系统代码。 此计数器仅显示最后一个观察到的值;它不是平均值。
该分析检查每小时增加 10 兆字节的趋势。 在负载下，服务器可能会使用系统缓存来缓存 I/O 活动，例如磁盘。 与进程 IO 数据操作/秒和进程 IO 其他操作/秒的分析相关联。
处理器利用率分析和进程过度使用处理器
“% 处理器时间”是处理器执行非空闲线程所花费的时间百分比。 它通过测量空闲线程在样本间隔中处于活动状态的持续时间来计算，然后从间隔持续时间中减去该时间。 （每个处理器都有一个空闲线程，当没有其他线程准备好运行时，该线程会消耗周期。此计数器是处理器活动的主要指标，并显示样本间隔期间观察到的忙碌时间的平均百分比。 它通过监视服务处于非活动状态的时间以及从 100% 减去该值来计算。
此分析检查每个处理器的利用率是否大于 60%。 如果是这样，请确定它是高用户模式 CPU 还是高特权模式。 如果您怀疑 CPU 处于高级特权模式，请参考“特权模式 CPU 分析”。 如果怀疑用户模式处理器瓶颈，请考虑使用进程探查器分析导致 CPU 使用率较高的函数。 有关详细信息，请参阅参考部分中的“如何：识别导致生产环境中服务器应用程序出现高用户模式 CPU 瓶颈的函数”一文。
处理器队列长度分析
“处理器队列长度”是处理器队列中的线程数。 与磁盘计数器不同，此计数器仅显示就绪线程，而不显示正在运行的线程。 即使在具有多个处理器的计算机上，处理器时间也存在单个队列。 因此，如果计算机有多个处理器，则需要将此值除以处理工作负荷的处理器数。 每个处理器的持续处理器队列少于 10 个线程通常可以接受，具体取决于工作负荷。
此分析确定平均处理器队列长度是否超过处理器数。 如果是这样，则可能表示处理器瓶颈。 将此分析与特权模式 CPU 分析和进程过度处理器使用分析结合使用。 处理器队列是已准备好但无法由处理器执行的线程的集合，因为当前正在执行另一个活动线程。 线程数量多于处理器数量的持续或反复出现的队列是处理器瓶颈的良好指示。
可以将此计数器与“Processor\% Processor Time”计数器结合使用，以确定应用程序是否可以从更多 CPU 中受益。 在处理器时间方面，即使在多处理器计算机上也只有一个队列。 因此，在多处理器计算机中，将“处理器队列长度”（PQL）值除以处理工作负荷的处理器数
如果CPU非常繁忙（利用率达到90%及以上），并且PQL平均值一直高于处理器的数量，那么可能存在处理器瓶颈，这种情况可以通过增加额外的CPU得到改善。 或者，可以在应用程序级别减少线程数和队列数。 这会导致上下文切换减少，这有利于降低 CPU 负载。 CPU 使用率较低而 PQL 较高的常见原因是处理器时间请求的到达是随机的，同时线程对处理器的时间需求不规则。 这意味着处理器不是瓶颈。 相反，你的线程逻辑需要改进。
如果怀疑用户模式处理器瓶颈，请考虑使用进程探查器分析导致 CPU 使用率较高的函数。 有关详细信息，请参阅参考部分中的“如何：识别导致生产环境中服务器应用程序出现高用户模式 CPU 瓶颈的函数”一文。
特权模式 CPU 分析
此计数器指示线程在特权模式下运行的时间百分比。 当应用程序调用作系统函数（例如执行文件或网络 I/O 或分配内存）时，这些作系统函数以特权模式执行。
高特权模式 CPU 表示计算机在系统 I/O 中花费的时间过多，而不是实际（用户模式）工作。 “% 特权时间”是进程线程在特权模式下执行代码所花费的时间百分比。 调用 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。 此阈值在下面提到的主题“如何修改默认主机限流设置”中有所记载。 默认情况下，数据库限制阈值中的主机消息计数设置为值 50,000，这将在以下情况下触发限制条件：
主机实例发布到订阅主机的工作、状态和挂起队列的消息总数超过 50,000。
后台处理表中的消息数或跟踪表中的消息数超过 500,000 条消息。
由于挂起的消息被包括在数据库计算的消息计数中，因此即使 BizTalk 服务器负载很低或没有负载，消息发布仍可能受到限制。
此分析检查数值是否为 1。 如果发生这种情况，请考虑一个行动方案，以减少数据库中的消息数量。 例如，确保 BizTalk SQL Server 作业在运行时没有错误，并使用 BizTalk 管理控制台中的组中心来确定消息生成是否是由大量挂起的消息引起的。
参考文献
BizTalk 高 In-Process 消息计数分析
主机限制设置中的“每个 CPU 进程内消息”设置是传递到尚未处理的终结点管理器（EPM）或 XLANG 的最大消息数。 此数字不包括从数据库检索的消息，但仍在内存中队列中等待传递。 可以使用 BizTalk：Message Agent 性能对象类别下的进程内消息计数性能计数器来监视进程内消息数。 此参数在考虑限流条件时向限流机制提供建议。 实际阈值受自动调整的影响。 可以通过监视进程内消息计数性能计数器来验证实际阈值。
对于大型消息方案，可以将此参数设置为较小的值，其中平均消息大小较高，或者处理消息可能需要大量消息。 如果某个场景经常受到基于内存的限制，并且内存阈值自动调整到非常低的值，这就会很明显。 此类行为将指示出站传输应并发处理更少的消息，以避免过多的内存使用率。 此外，对于适配器在一次处理一些消息时更高效的情况（例如，发送到限制并发连接的服务器时），可将此参数调整为低于默认值的值。
此分析检查高 In-Process 消息计数器，以确定是否发生了此类节流。 如果是这样，请考虑调整“每个 CPU 的In-Process 消息”设置。 此参数仅影响出站消息限流。 在“每个 CPUIn-Process 消息数”设置中输入值 0，以根据每个 CPU 的进程内消息数禁用限速。 “In-Process 每个 CPU 消息”设定的默认值为 1,000。 请注意，修改此值还可能会影响消息的低延迟和/或 BizTalk 资源的效率。
参考文献
BizTalk 高消息传送速率分析
对于出站（已传递）消息，如果主机实例的消息传递传入速率超出消息传递传出率 * 指定的超速驱动因素（百分比）值，BizTalk Server 将限制消息传递。 在“消息处理限制设置”对话框中，可以配置速率过载系数（百分比）参数。 出站消息的基于速率的节流主要通过在从内存队列中删除消息并将消息传送到终结点管理器（EPM）或业务流程引擎进行处理之前引入延迟来实现。 不会采取任何其他动作来实现出站消息的速率限制。
出站流量限制可能导致消息传递延迟，消息可能会在内存队列中积累，并导致出队线程被阻止，直到流量限制情况得到缓解。 当关闭线程被阻止时，不会将其他消息从 MessageBox 提取到内存中队列进行出站传送。
此分析检查“高消息传递速率”计数器中的值是否为 1。 高消息传递率可能是由于处理复杂性高、出站适配器缓慢或系统资源的暂时短缺造成的。
参考文献
BizTalk 高进程内存分析
如果输入 1 到 100 之间的值，则 BizTalk 进程内存使用率限制阈值设置是与工作集大小和进程可用虚拟内存的总和相比使用的内存百分比。 默认情况下，BizTalk 进程内存使用率限制设置为 25。 指定百分比值时，将定期重新计算进程内存阈值。 如果用户指定百分比值，则会根据要提交的可用内存和当前进程内存使用情况来计算该值。
此分析检查高进程内存计数器中是否存在值1。 如果发生这种情况，请尝试使用调试 Diag 来确定内存增加的原因（请参阅内存泄漏检测分析中的引用）。 请注意，进程在启动期间消耗大量内存是正常的，这最初可能显示为内存泄漏，但当进程无法释放不再需要的内存时，会发生真正的内存泄漏，从而减少一段时间内的可用内存量。 有关如何在 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 入站延迟分析平均延迟（以毫秒为单位），从消息引擎从适配器接收文档到发布到消息盒为止。 降低延迟对 BizTalk 的某些用户来说很重要，因此跟踪文档在入站适配器中花费的时间量非常重要。
下面是显示如何测量延迟的图表。
| 1 | 2 | 3 | 4 | 5 | 6 |
|---|---|---|---|---|---|
| 适配器接收消息并将其提交到引擎，适配器在消息递交给引擎之前所做的工作未在这些性能计数器中捕获。 | 引擎从适配器接收消息，执行接收管道、映射、订阅评估、在 DB 中保留消息。 | 编排或 Solicit-Response 端口运行并生成响应消息。 | 响应消息从消息引擎的队列中取出，执行发送管道，进行映射。 | 消息引擎向适配器提供响应消息。 | 适配器通知引擎消息已完成。 |
| 我 | |||||
| RR | RR | RR | |||
| O | O | O | |||
| OA | 办公自动化 (OA) |
I = 入站延迟
RR = 请求响应延迟
O = 出站延迟
OA = 出站适配器延迟
假设延迟较低，此分析将检查文档是否在入站适配器中花费了 5 秒以上。 这可能表示通过此主机实例中的入站适配器传输消息时出现处理延迟。 如果此主机实例中存在多个入站适配器，请考虑将它们分成自己的主机，以确定哪个入站适配器具有较高的延迟。
参考文献
BizTalk 消息传递限制状态分析
BizTalk 消息传递的节流状态是节流的主要指示器之一。 它是一个标志，指示系统是否正在限制消息传递（影响 XLANG 消息处理和出站传输）。 限流条件通过计数器的数值来指示。 下面是值及其各自含义的列表：
| 节流条件 | DESCRIPTION |
|---|---|
| 0 | 没有限速 |
| 1 | 由于消息传递速率不平衡而导致限制（输入速率超过输出速率） |
| 3 | 由于进程中的消息计数高而导致的限流 |
| 4 | 进程内存压力导致的节流 |
| 5 | 由于系统内存压力而导致限流 |
| 9 | 由于线程数量较高而导致的限流 |
| 10 | 由于用户覆盖交付而限流 |
此分析检查每个值，并为每个值提供特定的警报。
参考文献
BizTalk MessageBox 数据库连接失败分析
此性能计数器是自主机实例启动以来尝试并失败的数据库连接数。 如果托管 BizTalk 数据库的 SQL Server 服务因任何原因变得不可用，数据库群集会将资源从活动计算机传输到被动计算机。 在此故障转移过程中，BizTalk Server 服务实例遇到数据库连接失败，并自动重启以重新连接到数据库。 在完成故障转移并接管资源后，运作中的数据库计算机（之前为被动计算机）开始处理数据库连接。
当 BizTalk Server 运行时无法与 MessageBox 或管理数据库通信时，会发生 DBNetLib（数据库网络库）错误。 发生这种情况时，捕获异常的 BizTalk Server 运行时实例将关闭，然后每隔一分钟循环检查数据库是否可用。 有关本主题的详细信息，请参阅参考部分。
当客户端启动与服务器的 TCP/IP 套接字连接时，客户端通常会连接到服务器上的特定端口，并请求服务器通过临时端口或短生存期 TCP 或 UDP 端口响应客户端。 在 Windows Server 2003 和 Windows XP 上，客户端应用程序使用的默认临时端口范围为 1025 到 5000。 在某些情况下，默认范围内的可用端口可能会耗尽。 有关本主题的详细信息，请参阅参考部分。
此分析检查是否存在数据库连接失败的情况。 数据库连接失败至关重要，因为 BizTalk 在没有数据库的情况下无法正常运行。 如果数据库连接失败的原因未知，请考虑下面列出的引用和/或联系Microsoft支持人员来确定连接失败的性质。
参考文献
BizTalk 消息发布限制状态分析
BizTalk 消息发布限制状态是限制的主要指标之一。 它是一个标志，指示系统是否正在限制消息发布（影响 XLANG 消息处理和入站传输）。限制条件由计数器的数值指示。 下面是值及其各自含义的列表：
| 节流条件 | DESCRIPTION |
|---|---|
| 0 | 没有限速 |
| 2 | 由于消息发布速率不平衡而导致限制（输入速率超过输出速率） |
| 4 | 进程内存压力导致的节流 |
| 5 | 由于系统内存压力而导致限流 |
| 6 | 数据库增长导致的限制 |
| 8 | 由于会话计数较高而导致的限流 |
| 9 | 由于线程数量较高而导致的限流 |
| 11 | 由于用户设置覆盖在发布过程中而导致限流 |
此分析检查每个值，并为每个值提供特定的警报。
参考文献
BizTalk 业务流程驻留在内存中
主机实例当前托管的业务流程实例数。 虽然内存中编排的突增或爆发可能被视为正常，但其增加的趋势可能表明内存中编排的“堆积如山”。 当 BizTalk 无法解除消息/业务流程实例冻结时，可能会出现随时间推移的趋势增加。 尝试将此计数器与“XLANG/s Orchestrations（？）\Dehydratable orchestrations”关联，其中问号（？）表示该计数器与此计数器实例相同。
如果大量业务流程驻留在内存中，并且如果少量业务流程可解除冻结，则业务流程可能在内存中处于空闲状态，并可能导致内存泄漏情况。 将此分析与“\XLANG/s Orchestrations(*)\Idle orchestrations”相关联（如果存在）。 BizTalk空闲业务流程的上升趋势更能表明内存泄漏，因为无法解除业务流程实例的休眠状态。
此分析检查驻留在内存中的编排是否呈现上升趋势，如果内存中驻留的编排中有超过 50 个% 是不可解除冻结的。
参考文献
BizTalk 专用字节分析
这是主机实例分配的专用内存的兆字节，与“\Process\\Private Bytes”性能计数器相当。 专用字节是进程分配的无法与其他进程共享的内存的当前大小（以字节为单位）。 此分析确定任何主机实例是否消耗了大量的系统内存，并且内存消耗是否会随着时间的推移而增加。 只要主机实例将内存返回到系统，占用大量内存的主机实例就没问题。 在图表中查找增加的趋势。 增长趋势持续很长一段时间可能表明内存泄漏。
此分析检查每小时增加 10 MB 的趋势。 将此分析与可用内存分析和内存泄漏分析相关联。 此外，请记住，新启动的主机实例最初会在正常启动行为时显示为内存泄漏。 内存泄漏是进程继续消耗内存，并且不会在很长一段时间内释放内存。 如果怀疑内存泄漏情况，请阅读下面引用的“BizTalk 消息传送中的内存增长”一文。 否则，请安装和使用调试 Diag 工具。 有关调试 Diag 工具的详细信息，请参阅参考部分。
参考文献
BizTalk 虚拟字节分析
这是为主机实例的虚拟内存保留的兆字节。 此分析确定任何主机实例是否消耗大量系统的内存，以及主机实例是否随时间推移而增加内存消耗。 只要主机实例将内存返回到系统，占用大量内存的主机实例就没问题。 在图表中查找增加的趋势。 增长趋势持续很长一段时间可能表明内存泄漏。
此分析检查虚拟字节数每小时增加 10 MB 的趋势。 将此分析与可用内存分析和内存泄漏分析相关联。 此外，请记住，新启动的主机实例最初会在正常启动行为时显示为内存泄漏。 内存泄漏是进程继续消耗内存，并且不会在很长一段时间内释放内存。 如果怀疑内存泄漏情况，请阅读下面的“BizTalk 消息传送中的内存增长”一文。 否则，请安装和使用调试 Diag 工具。 有关调试 Diag 工具的详细信息，请参阅参考部分。
参考文献
BizTalk 消息代理数据库会话节流分析
这是与 MessageBox 的开放数据库连接数，与其对应的 BizTalk 限制设置进行比较的结果。 “每个 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 消息计数器，以确定其计数值是否大于其限流配置的 80%，这表示可能会出现限流情况。
参考文献
BizTalk：消息代理进程内消息计数限制阈值分析
这是服务类正在处理的并发消息数的当前阈值。 主机限制设置中的“每个 CPU 进程内消息”设置是传递到尚未处理的终结点管理器（EPM）或 XLANG 的最大消息数。 这不包括从数据库检索的消息，但仍在内存队列中等待传递。 可以使用 BizTalk：Message Agent 性能对象类别下的进程内消息计数性能计数器来监视进程内消息数。 此参数为节流机制提供了提示，以便考量节流条件。 实际阈值受自动调整的影响。 可以通过监视进程内消息计数性能计数器来验证实际阈值。
对于大型消息方案（其中平均消息大小较高或处理消息可能需要大量消息），此参数可以设置为较小的值。 某个场景被认为是大型消息场景，如果内存限制过于频繁发生，并且内存阈值自动调整至非常低的水平。 此类行为将指示出站传输应并发处理更少的消息，以避免过多的内存使用率。 此外，对于适配器在一次处理一些消息时更高效的情况（例如，发送到限制并发连接的服务器时），可将此参数调整为低于默认值的值。 此分析检查非默认值情况下的高 In-Process 消息计数节流阈值。
参考文献
BizTalk 消息代理进程内存使用情况 (MB) 节流分析
这是当前进程的内存使用情况（MB）。 如果发布批处理需要较高的内存或处理消息的线程过多，则可能发生 BizTalk 进程内存调节。 如果系统似乎过度限制，请考虑增加与主机的进程内存使用阈值关联的值，并验证主机实例是否未生成“内存不足”错误。 如果由于增加进程内存使用的阈值而引发“内存不足”错误，请考虑减少内部消息队列的大小以及每个 CPU 的进程内消息的阈值。 此策略在大型消息处理方案中尤其相关。
如果 BizTalk 服务器定期耗尽虚拟内存，请考虑 BizTalk Server 64 位。 64 位服务器上的每个进程最多可以处理 4 TB 的虚拟内存，而不是 32 位中的 2 GB。 通常，强烈建议使用 64 位 BizTalk 和 64 位 SQL Server。 有关详细信息，请参阅“BizTalk Server 64 位支持”参考。 此分析检查进程内存使用率是否大于其自身节流阈值的 80%。 默认情况下，BizTalk 进程内存使用率限制设置是进程可用的虚拟内存的 25%。 /3GB 开关对此设置没有影响。
参考文献
BizTalk：消息代理进程内存使用量（MB）限制阈值分析
这是当前进程内存使用量（MB）的当前阈值。 可以根据此进程可用的实际内存量及其内存消耗模式动态调整阈值。 如果发布批处理需要较高的内存或处理消息的线程过多，则可能发生 BizTalk 进程内存调节。 如果系统似乎过度限制，请考虑增加与主机的进程内存使用阈值关联的值，并验证主机实例是否未生成“内存不足”错误。 如果通过增加进程内存使用阈值来引发“内存不足”错误，请考虑减少每个 CPU 阈值的内部消息队列大小和进程内消息的值。 此策略在大型消息处理方案中尤其相关。
如果 BizTalk 服务器定期耗尽虚拟内存，请考虑 BizTalk Server 64 位。 64 位服务器上的每个进程最多可以处理 4 TB 的虚拟内存，而不是 32 位中的 2 GB。 通常，强烈建议使用 64 位 BizTalk 和 64 位 SQL Server。 有关详细信息，请参阅“BizTalk Server 64 位支持”参考。 此分析检查进程内存限制是否设置为非默认值。