如何排查BizTalk Server进程中的内存泄漏或内存不足异常

  • 项目

本文介绍如何在 Microsoft BizTalk Server 的BizTalk Server过程中排查内存泄漏或内存不足异常。

原始产品版本：BizTalk Server 2010、2009
原始 KB 编号： 918643

摘要

内存泄漏是一个常见问题。 在 Microsoft BizTalk Server 中，可能需要尝试几个步骤才能找到内存泄漏或内存不足 (OOM) 异常的具体原因。 本文讨论评估内存使用情况和可能的内存相关问题时要考虑的重要事项。 这些注意事项包括以下内容：

  • 物理 RAM
  • 大型消息处理
  • 使用 /3GB 开关
  • 自定义组件的使用
  • 系统运行的 Microsoft .NET Framework版本
  • 处理器数量

当 Microsoft Windows 任务管理器中的内存使用量占用物理 RAM 的 50% 以上时，BizTalk Server进程可能会遇到内存泄漏。 当内存使用率增加时，内存泄漏可能会导致内存不足异常，直到进程耗尽系统内存或进程停止运行。 对于此问题，请考虑以下事项：

物理 RAM 和内存使用情况

由于进程使用大约一半的物理 RAM 可能是预期行为，因此请使用内存使用量作为准则。 例如，如果BizTalk Server具有 4 GB (GB) RAM，并且BizTalk Server进程使用大约 500 MB (MB) RAM，则可能不会发生泄漏。 如果BizTalk Server进程使用大约 1 GB 的 RAM，则可能存在内存泄漏或内存过高的情况。 内存消耗可能是由长时间运行的存储过程或业务流程引起的。 请确保知道 BizTalk 主机通常使用多少内存来确定是否发生了内存泄漏或内存过高的情况。

大型消息

当BizTalk Server处理大型消息时，系统似乎有内存泄漏。 但是，消息可能使用大量内存。

此外，请注意，如果BizTalk Server正在处理大型消息，则可能预期内存使用率过高。 你可能想要升级硬件以满足环境中BizTalk Server的性能要求。

重现内存泄漏需要多长时间

内存泄漏可能会立即发生，也可能随着时间的推移而累积。 这两种情况都很常见。

在 32 位计算机上使用 /3GB 开关

通常，进程可以访问 2 GB 的虚拟地址空间。 /3GB 开关是需要更多可寻址内存的系统的选项。 此选项可能会改善处理消息的内存使用率。 但是， /3GB 开关 只允许 1 GB 的可寻址内存用于内核模式操作。 此外，此开关可能会增加池内存不足的风险。

在 32 位版本的 Windows 上启用 /3GB 开关 时，如果进程可识别大地址，则进程可以访问 3 GB 的虚拟地址空间。 当可执行文件在映像标头中设置了 IMAGE_FILE_LARGE_ADDRESS_AWARE 标志时，进程可识别大地址。 由于 BizTalk 进程可识别大地址，因此 BizTalk 将受益于 /3GB 交换机。

如果 32 位 BizTalk 主机实例在 64 位版本的 Windows (AMD64) 上运行，则 BizTalk 进程受益于 4 GB 内存地址空间，因为 BizTalk 具有大地址感知功能。 因此，将高内存应用程序移动到 64 位服务器可能是最佳解决方案。

64 位版本的 Windows (AMD64) 上的 64 位 BizTalk 进程具有 8 TB 的可寻址内存。

还应考虑进程使用的虚拟字节和专用字节。 BizTalk 主机实例 (（.NET Framework应用程序) 可能会在虚拟字节值达到 2 GB 之前收到内存不足错误。 即使没有 /3GB 开关 的 32 位版本的 Windows (上的进程可寻址的最大内存) 2 GB，也可能发生这种情况。 有关出现这种情况的原因的说明，请访问以下 Microsoft 开发人员网络 (MSDN) 网站：
ASP.NET 性能监视和何时向管理员发出警报

/3GB 开关还会将 BizTalk 进程的最大专用字节数从 800 MB 增加到 1800 MB。 有关启用 /3GB 开关.NET Framework应用程序性能的详细信息，请访问第 17 章 - 优化 .NET 应用程序性能。

下表汇总了此信息，并包括虚拟字节和专用字节的实际限制。

流程 Windows 具有大型地址感知进程) 的可寻址内存 ( 虚拟字节的实际限制 专用字节的实际限制
32 位 32 位 2 GB 1400 MB 800 MB
32 位 具有 /3GB 的 32 位 3 GB 2400 MB 1800 MB
32 位 64 位 4 GB 3400 MB 2800 MB
64 位 64 位 8 TB 不适用 不适用

有关 32 位与 64 位 Windows 的可寻址内存的详细信息，请访问 Windows 和 Windows Server 版本的内存限制。

下表列出了不同版本的BizTalk Server的 PAE 和 3 GB 支持性。

产品 Pae 3 GB
BizTalk Server 2004 是 否
BizTalk Server 2006 是 是
BizTalk Server 2006 R2 是 是
BizTalk Server 2009 是 是

如果必须启用 /3GB 开关才能满足运行 BizTalk Server 的计算机的性能要求，则可能需要考虑将服务器添加到 BizTalk 组。 这使你可以横向扩展内存密集型主机实例。

启用 /3GB 开关 时，在 Internet Information Services (IIS) 进程中运行的 BizTalk 组件也可能受益。

运行 Windows SharePoint Services 2.0 或更高版本或 SharePoint Portal Server 2003 SP2 或更高版本的计算机不支持 /3GB 开关。 Windows SharePoint Services 2.0 或更高版本或 SharePoint Portal Server 2003 Service Pack 2 或更高版本中不支持 Windows Server 2003 /3GB 开关。

自定义组件的使用

如果使用自定义组件（如管道或服务组件），则必须知道这些组件的功能。 还应了解这些组件对内存使用量的潜在影响。 组件转换文档时，会出现常见的内存问题。 转换操作是内存密集型操作。 转换文档时，BizTalk Server将消息流传递到 BizTalk 进程中的 Microsoft .NET Framework XslTransform 类。

当存在密集的字符串操作时，会出现另一个常见问题。 密集的字符串操作可能会消耗大量记忆。 有关提高性能的方法的详细信息，请访问 提高托管代码性能。

.NET Framework的版本

Microsoft .NET Framework 2.0 和 .NET Framework 1.1 具有不同的内存行为。 因此，你可能会看到它们之间的不同结果。 如果使用.NET Framework，请确认已安装最新的 .NET Framework Service Pack 1。 此服务包可解决多个已知内存问题。

处理器数量

公共语言运行时 (CLR) 具有以下垃圾回收器 (GC) ：

  • 工作站 (Mscorwks.dll)
  • 服务器 (Mscorsvr.dll)

如果运行 BizTalk Server 的计算机是多处理器系统，则.NET Framework使用执行引擎的服务器版本。 这是默认行为。 服务器垃圾回收器旨在实现最大吞吐量。 此外，服务器垃圾回收器会进行缩放以提供高性能。 此垃圾回收器分配内存，然后释放内存，以在系统上提供高性能。 因此，与某些.NET Framework组件一起运行BizTalk Server的计算机似乎存在内存泄漏。 但是，在此方案中，内存使用率过高是预期行为。 如果计算机耗尽系统内存，或者进程由于可寻址内存不足而停止工作，则可能存在内存泄漏情况。

如果运行 BizTalk Server 的计算机是单处理器系统，则.NET Framework使用执行引擎的工作站版本。 这是默认行为。 工作站垃圾回收器分配算法不是针对缩放或最大吞吐量而设计的。 此垃圾回收器使用并发垃圾回收器方法。 这些方法专为具有复杂用户界面的应用程序而设计。 此类应用程序可能需要更积极的垃圾回收。

重要

此部分（或称方法或任务）介绍了修改注册表的步骤。 但是，如果错误地修改注册表，可能会出现严重问题。 因此，请确保仔细执行这些步骤。 为了加强保护，应先备份注册表，再进行修改。 如果出现问题，可以还原注册表。 有关如何备份和还原注册表的详细信息，请参阅如何备份和还原 Windows 中的注册表。

有时，在多处理器系统上运行执行引擎的工作站版本可能很合适。 可以使用以下注册表项切换到执行引擎的工作站版本。

BizTalk 2006 及更高版本

Create以下内容CRL Hosting具有相应值的字符串注册表项：

  • 项：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkHostName\CLR Hosting
  • 值名称：Flavor
  • 值数据：wks

BizTalk 2004

Create以下内容CRL Host具有相应值的字符串注册表项：

  • 项：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSvc{GUID }\CLR Hosting
  • 值名称：Flavor
  • 值数据：wks

有关详细信息，请访问.NET Framework中 Run-Time 技术的性能注意事项。

以下是常见原因和解决方法：

进程和物理内存使用限制阈值

可以在 BizTalk Server 2006 和更高版本中更改进程内存使用量和物理内存使用限制阈值。

  • 默认情况下， “进程内存使用 限制阈值”设置为 25。 如果超出此值，并且 BizTalk 进程内存使用率超过 300 MB，则可能会发生限制条件。 在 32 位服务器上，可以将进程内存使用值增加到 50。 在 64 位服务器上，可以将此值增加到 100。 这允许 BizTalk 进程在发生限制之前消耗更多内存。

  • 物理内存使用限制阈值的默认值为 0。 此阈值度量总系统内存。 因此，如果配置了除 0 以外的值，则非 BizTalk 进程使用高内存时可能会出现限制条件。

解除冻结限制阈值

当业务流程在 64 位主机上运行时，默认内存解除冻结阈值可能会导致过多的冻结。 有关此问题的详细信息，请参阅 解除冻结默认属性。

注意

BizTalk Server 2006 及更高版本中支持 64 位主机。

在 32 位主机实例中的等效硬件上，使用默认内存冻结限制阈值运行相同的业务流程时，观察到的冻结是名义上的。

由于 64 位体系结构提供的扩展内存地址空间 (16 TB 而不是 4 GB) ，因此 64 位主机实例分配的内存比 32 位主机实例多。 这可能会导致超出默认内存限制阈值。

若要解决此问题，请更改 BTSNTSvc64.exe.config 文件中 的 VirtualMemoryThrottlingCriteria 和 PrivateMemoryThrottlingCriteria 值。 使用 \Process\Virtual Bytes 和 \Process\Private Bytes 性能监视器 计数器来确定业务流程实例分配的最大内存量。

  • 根据以下条件为这两个属性设置 OptimalUsage 值：

    • VirtualMemoryThrottlingCriteria： \Process\Virtual Bytes 值 + 10%
    • PrivateMemoryThrottlingCriteria： \Process\Private Bytes 值 + 10%

  • 将这两个属性的 MaximalUsage 设置为 OptimalUsage 值 + 30%

例如，如果业务流程实例的 \Process\Virtual Byte 性能监视器 计数器值为 5,784,787,695 字节 (5,517 MB) ， 将 VirtualMemoryThrottlingCriteria 的 OptimalUsage 值设置为 6,069 MB (5,784,787,695 * 1.10 = 6,363,266,464.5 字节) 。

将 VirtualMemoryThrottlingCriteria 的 MaximalUsage 值设置为 7,889 MB (6,363,266,464.5 * 1.30 = 8,272,246,403.85 字节) 。

如果 \Process\Private Bytes 性能监视器 计数器值为 435689400 字节 (415 MB) ，请将 PrivateMemoryThrottlingCriteria 的 OptimalUsage 值设置为 457 MB (435689400 * 1.10 = 479258340 字节) 。

将 PrivateMemoryThrottlingCriteria 的 MaximalUsage 值设置为 594 MB (479258340 * 1.30 = 623035842) 。

对于此示例，将在 BTSNTSvc64.exe.config 文件中指定以下值以减少限制。

性能监视器计数器 分配的内存 OptimalUsage MaximalUsage
\Process\Virtual Bytes 5,784,787,695 字节 (5517 MB) 6069 7889
\Process\Private Bytes 435,689,400 字节 (415 MB) 457 594

然后，这些值将在 BTSNTSvc64.exe.config 文件中表示，如下所示：

<xlangs>
    <Configuration>
       <Dehydration>
         <VirtualMemoryThrottlingCriteria OptimalUsage="6069" MaximalUsage="7889" IsActive="true" />
         <PrivateMemoryThrottlingCriteria OptimalUsage="457" MaximalUsage="594" IsActive="true" />
       </Dehydration>
    </Configuration>
</xlangs>

若要确定哪个主机实例正在运行业务流程，可以匹配来自 \BizTalk： Messaging\ID Process 和 \Process\ID Process 性能监视器 计数器的 ID 进程。 然后，检查相应的 \Process\Virtual Bytes 和 \Process\Private Bytes 性能监视器 计数器显示的 Average 值。

注意

当用户在 2008 SQL Server运行时，用户也应注意的信息高脱水可能导致性能BizTalkMsgBoxDb显著降低。

BizTalk Server Service Pack 和累积更新

BizTalk Server Service Pack 和累积更新包括最新的修补程序。 其中包括影响已知 System.OutOfMemoryException 问题的那些问题。

HeapDeCommitFreeBlockThreshold

默认情况下， HeapDeCommitFreeBlockThreshold 注册表项值为 0。 值 0 表示堆管理器每 4 KB (KB) 可用页面取消提交。 取消提交操作可能会导致虚拟内存碎片。 堆管理器中设置的大小 HeapDeCommitFreeBlockThreshold 取决于系统正在执行的工作类型。 建议使用大小0x00040000作为起始值。

在更改注册表项的值之前， HeapDeCommitFreeBlockThreshold 请考虑以下信息：

  • 此更改仅适用于内存碎片问题。
  • 此更改是系统范围的。 因此，大多数进程会在启动时使用更多内存。
  • 仅将BizTalk Server作为主要任务的系统考虑此更改。

为了帮助减少虚拟内存碎片，可以通过在 下更改以下注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager的值来增加堆管理器中的设置大小HeapDeCommitFreeBlockThreshold：

  • 值名称：HeapDeCommitFreeBlockThreshold
  • 值类型：REG_DWORD
  • 值数据：0x00040000 (这是建议的起始值。)
  • 默认值：不存在

转换操作

当BizTalk Server在接收端口、发送端口或 中XLANG对相当大的消息执行 XML 转换操作时，XSL 转换会将整个消息加载到内存中。

若要解决此问题，请使用以下某种方法：

  • 减少同时BizTalk Server进程的消息数。
  • 减小正在转换的 XML 消息的大小。

对象 System.Policy.Security.Evidence 经常用于转换，可能会消耗大量内存。 如果映射包含使用内联 C# (或任何其他内联语言) 的脚本 functoid ，则会在内存中创建程序集。 对象 System.Policy.Security.Evidence 使用实际调用程序集的 对象。 这种情况会创建一个在 BizTalk 服务重启之前不会删除的 rooted 对象。

大多数默认 BizTalk functoids 都作为内联脚本实现。 这些项可能导致 System.Byte[] 对象收集到内存中。 若要最大程度地减少内存消耗，建议将使用这些 functoids 内存的任何映射放入小型程序集中。 然后，引用该程序集。 使用下图确定哪些 functoids 使用内联脚本，哪些 functoids 不使用内联脚本。

第二列中， “是 ”表示这是 functoid 作为内联脚本实现的，并且将导致 System.Byte[] 对象收集到内存中。 否 表示此 functoid 脚本未作为内联脚本实现，并且不会导致 System.Byte[] 对象收集到内存中。

Functoids 内联脚本？
所有字符串 Functoid 是
所有数学 Functoid 是
除 IsNil 之外的所有逻辑 Functoid 是
Logical IsNil Functoid 否
所有日期/时间 Functoid 是
所有转换 Functoid 是
所有科学 Functoid 是
所有累积 Functoid 是
所有数据库 Functoid 否
高级 Functoid 内联脚本？
循环 Functoid 否
Value-Mapping 平展 Functoid 否
Assert Functoid 否
表提取程序 Functoid 否
表循环 Functoid 否
使用内联 C 编写 Functoid 脚本# 是
使用内联 JScript.NET 编写 Functoid 脚本 是
使用 Inline Visual Basic .NET 编写 Functoid 脚本 是
使用内联 XSLT 编写 Functoid 脚本 否
使用内联 XSLT 调用模板编写 Functoid 脚本 否
编写调用外部程序集的 Functoid 脚本 否
Nil 值 Functoid 否
值映射 Functoid 否
批量复制 Functoid 否
迭代 Functoid 否
Index Functoid 否
记录计数 Functoid 否

BizTalk Server 2006 及更高版本显著改进了大型文档的内存管理。 为此，BizTalk Server实现可配置的消息大小阈值，以便在转换操作期间将文档加载到内存中。 默认消息大小阈值为 1 MB。 有关 TransformThreshold 设置的详细信息，请访问如何BizTalk Server处理大型消息。

大型属性值和大型元素值

当BizTalk Server对 XML 文档执行接收管道或发送管道时，如果文档包含以下一个或多个实体，则会在内存中处理有效负载：

  • 较大的属性值
  • 大型元素值
  • 大型属性或元素标记

若要解决此问题，请限制这些实体的大小。 如果此方法不可行，请确保 BizTalk HOST 实例不会同时处理多个文档，例如这些文档。

自定义管道组件

你使用的是将整个流加载到内存中的自定义管道组件。 BizTalk Server附带的所有组件（转换除外）都支持流式处理。 这些组件在流式处理期间不会使用太多内存。 但是，自定义管道组件可能不支持流式处理。

在沉重压力下进行流式处理

当主机在承受沉重压力下运行时，发送主机内存不足。 BizTalk Server发送管道和发送适配器支持流式处理。 在流式处理中，每个组件将流的小片段加载到内存中。 由于每条消息都包含其他数据结构，以及可能很大或很小的消息上下文，因此此行为会影响BizTalk Server在重压力下的行为。

BizTalk Server的行为会受到影响，因为引擎加载了预配置的消息数。 引擎加载的消息数基于表的 LowWaterMark 字段和 HighWaterMark 字段中 Adm_serviceClass 显示的值。 表 Adm_serviceClass 位于 BizTalk 管理数据库中。 这些值控制同时BizTalk Server处理或发送的消息数。

HighWaterMark 值是引擎同时处理的消息总数。 默认值为每个 CPU 200 条消息。 因此，在 8 处理器服务器上，发送主机将尝试同时处理 1,600 条消息 (200 * 8) 。

如果假定每条消息为 50 KB，则消息等于 80 MB (1,600 * 50=80,000 KB) 。

若要解决此问题，可以更改数据库中 的 HighWaterMark 值和 LowWaterMark 值。 使用的值取决于消息的大小。 对于 BizTalk Server 2006 及更高版本，可以更改默认主机限制设置。

尝试简化问题

如果已确定内存泄漏，请尝试通过删除自定义组件或简化映射来确定原因。 此外，尝试使用简单的业务流程或简单的解决方案重现问题。 通常，应为接收适配器创建单独的接收主机。 还应为发送适配器创建单独的发送主机。 使用此方法时，每个适配器都可以在单独的进程中运行。 因此，如果BizTalk Server进程遇到内存不足的情况，你将知道涉及哪些组件。

故障排除步骤

若要排查内存不足情况，请使用调试诊断工具监视一段时间内的内存分配。 调试诊断工具可以创建和分析内存泄漏转储文件 (.dmp) 。 排查内存泄漏问题时，目标是在高内存条件重现之前附加 Leaktrack.dll ，以捕获内存随时间推移的增长。 调试 诊断工具包含Leaktrack.dll。

  1. 安装调试诊断工具。

    可从 Microsoft 下载中心下载以下文件：
    立即下载调试诊断工具包

    有关如何下载 Microsoft 支持文件的详细信息，请参阅如何从 联机服务 获取 Microsoft 支持文件。

    Microsoft 扫描了此文件中的病毒。 Microsoft 使用了在文件发布之日提供的最新病毒检测软件。 该文件存储在安全性增强的服务器上，有助于防止对文件进行任何未经授权的更改。

  2. 使用性能监视器收集有关系统性能的数据。 此数据可能提供有关BizTalk Server环境效率的重要指标。 目标是捕获一段时间内的进程性能。 因此，请在发生内存泄漏之前启用性能监视器日志记录。

如何使用性能监视器日志记录

以下部分介绍如何使用性能监视器日志记录。

选择要记录的数据

若要选择要记录的数据，请使用适用于操作系统的方法：

  • 对于 Windows Server 2008 和 Windows Server 2008 R2

    1. 在“管理工具”中，打开“可靠性和性能监视器”。

    2. 右键单击“性能监视器”，单击“新建”，然后单击“数据收集器集”。

    3. 在“ 名称 ”框中，键入描述性名称，然后单击“ 下一步”。

    4. 记下 根 目录，然后单击“ 下一步”。

    5. 单击“ 立即启动此数据收集器集”，然后单击“ 完成”。

    6. 展开 “数据收集器集”，展开 “用户定义” ，然后选择文件。

    7. 右键单击“ 系统监视器日志”，然后单击“ 属性”。

    8. 单击“性能计数器”选项卡上的“添加”。选择以下对象，然后在选择每个对象后单击“添加”：

      • .Net CLR 异常
      • .Net CLR 内存
      • BizTalk：消息传送
      • BizTalk：TDDS
      • 内存
      • 进程
      • 处理器
      • XLANG/s 业务流程

      如果SQL Server是本地的，则还要添加以下对象：

      • SQLServer：数据库
      • SQLServer：常规统计信息
      • SQLServer：内存管理器

    9. 单击“确定”。

    10. 将 “采样间隔”值 框更改为 5 秒。

      注意

      示例间隔值和开始监视的时间是主观的。 这些值取决于何时重现内存泄漏。 由于日志文件可能很大，因此请指定一个间隔，在该时间间隔中，你可以获取必须拥有的信息，而不会使服务器过大。

    11. 单击“确定”。

若要停止收集数据，请单击“操作”菜单上的“停止”。

  • 对于 Windows Server 2003 或 Windows XP

    1. 展开 “性能日志和警报”。

    2. 右键单击“ 计数器日志”，然后单击“ 新建日志设置”。 此时将显示“ 新建日志设置” 对话框。

    3. 在“ 名称 ”框中，键入描述性名称，然后单击“ 确定”。

    4. 记下日志文件位置。 (还可以单击“ 日志文件 ”选项卡，然后单击“ 配置 ”以更改日志文件位置。)

    5. 单击“ 添加计数器”。

    6. 选择“ 所有计数器” 和“ 所有实例”。

    7. 在 “性能对象 ”列表中，选择以下对象。 选择每个对象后，单击“ 添加 ”。

      • .Net CLR 异常
      • .Net CLR 内存
      • BizTalk：消息传送
      • BizTalk：TDDS
      • 内存
      • 进程
      • 处理器
      • XLANG/s 业务流程

      如果SQL Server是本地的，则还要添加以下对象：

      • SQLServer：数据库
      • SQLServer：常规统计信息
      • SQLServer：内存管理器

    8. 单击“关闭”。

    9. 将数据 采样间隔 中的值更改为 5 秒。

      注意

      数据采样间隔值和开始监视的时间是主观的。 这些值取决于何时重现内存泄漏。 由于日志文件可能很大，因此请指定一个间隔，在该时间间隔中，你可以获取必须拥有的信息，而不会使服务器过大。

    10. 单击“确定”。 若要停止收集数据，请右键单击计数器日志的名称，然后单击“ 停止”。

获取转储文件

若要获取转储文件，请使用以下方法之一：

方法 1：自动

使用 DebugDiag 创建内存和处理泄漏规则是捕获内存转储的建议方法。 内存和句柄泄漏规则自动附加 Leaktrack.dll。 这用于跟踪内存分配。 若要创建内存和处理泄漏规则，请执行以下步骤：

  1. 启动调试诊断工具 1.1。

  2. 选择“ 内存”和“处理泄漏”，然后单击“ 下一步”。

  3. 选择 Btsntsvc.exe 进程，然后单击“ 下一步”。

  4. 在 “配置泄漏规则 ”页上，执行以下步骤：

    1. 单击以选中“激活规则时立即启动内存跟踪检查框。 否则，可以在 BTSNTSvc.exe 过程中注入 LeakTrack.dll 之前指定预热时间。

    2. 单击“ 配置”，然后执行以下操作：

      • 确认已选择“ 自动创建崩溃规则 ”。 选择此选项后，如果 BTSNTSvc.exe 进程停止，将自动创建内存转储。

      • 单击以选中“虚拟字节达到检查时生成用户转储”框，并保留默认值 1024。

      • 单击以选择 和每个附加检查框，并保留默认值 200。 通过选择虚拟字节访问选项，当虚拟字节使用 1024 MB 时，将自动创建内存转储。 如果虚拟字节增加 200 MB，则会自动创建另一个内存转储。

    3. 单击“保存并关闭”。

    4. 单击下一个。

    5. 在 “选择转储位置和规则名称 ”页上，单击“ 下一步”。

      注意

      还可以在此页上的“ 用户转储位置 ”框中更改转储文件的路径。

    6. 单击“ 完成 ”，立即使规则处于活动状态。

      注意

      规则状态现在为 “跟踪”。 每次创建内存转储时，“规则”选项卡上的“用户转储计数”列中的值都会增加。默认内存转储位置为 C:\Program Files\DebugDiag\Logs。

方法 2：手动

还可以手动附加 Leaktrack.dll 并手动获取内存转储文件。 这使你可以控制何时创建内存转储。 为此，请按照下列步骤操作：

  1. 启动调试诊断工具 1.1。
  2. 单击“ 进程 ”选项卡。
  3. 右键单击 Btsntsvc.exe 进程，然后单击“ 监视泄漏”。
  4. 在 “调试诊断工具 ”对话框中，单击“ 是”，然后单击“ 确定”。

Create崩溃规则来监视相同的 Btsntsvc.exe 进程，以防进程在创建内存转储之前停止：

  1. 启动调试诊断工具 1.1。
  2. 选择“ 崩溃”，然后单击“ 下一步”。
  3. 选择特定进程，然后单击“ 下一步”。
  4. 选择同一 Btsntsvc.exe 进程，然后单击“ 下一步”。
  5. 在 “高级配置 (可选) ”页上，单击“ 下一步”。
  6. 在 “选择转储位置和规则名称 (可选) ”对话框中，单击“ 下一步”。
  7. 选择“ 立即激活规则”，然后单击“ 完成”。

当进程达到 60% 到 80% 的 RAM 时，右键单击 Btsntsvc.exe 进程，然后单击“Create完全用户转储”。 如果 BizTalk 进程在创建用户转储之前停止，崩溃规则应生效并创建内存转储。

停止性能监视器日志记录

如果要捕获内存转储并性能监视器数据，请在创建内存转储后大约两分钟停止性能监视器日志记录。

分析转储文件

为了帮助确定内存泄漏的原因，可以使用调试诊断工具来分析转储文件。 为此，请按照下列步骤操作：

  1. 单击“ 高级分析 ”选项卡。
  2. 单击“ 添加数据文件”，然后找到.dmp文件。
  3. 选择 “内存压力分析 ”脚本，然后单击“ 开始分析”。

默认情况下，分析完成后，将在 文件夹中创建 C:\Program Files\DebugDiag\Reports (.mht 文件) 的分析报告文件。 报表文件也会显示在浏览器中。 报告文件包含分析结果。 此外，报告文件可能包含有关如何解决内存泄漏的建议。

如果使用自定义 DLL，可以添加自定义 .pdb 文件的符号路径以供分析。 为此，请按照下列步骤操作：

  1. 打开“调试诊断”工具。
  2. 在“工具”菜单上，单击“选项和设置”。
  3. 在“调试的符号搜索路径”框中，键入符号路径。

如果需要有关分析转储文件的帮助，请联系 Microsoft 客户支持服务。 有关客户支持服务电话号码的完整列表以及有关支持成本的信息，请访问 联系支持人员。

联系客户支持服务之前，请压缩转储文件、性能监视器日志、分析报告文件和更新的事件日志 (.evt 文件) 。 可能需要将这些文件发送给BizTalk Server支持工程师。