本文讨论如何收集和分析数据，以确定是否存在可以使用注册表项修正 MaxConcurrentApi 的问题。 此类问题也称为 MCA 问题。 此过程可帮助你确定基础结构中的哪些计算机受此问题影响。
适用于： Windows Server 2012 及更高版本、Windows 8 及更高版本
总结
从技术上看，MaxConcurrentApi定义每个可供 Netlogon 服务使用的安全通道的lsass.exe线程数。 此值在每台服务器的注册表中设置。 除非你已执行以下操作，否则不应更改它：
- 标识了显示 MCA 问题证据的特定服务器
- 计算每个受影响的服务器的特定
MaxConcurrentApi值
如果更改值而不遵循这些规则，则可能无法解决问题。 事实上，你可能会造成其他问题。
本文介绍如何使用以下过程识别应修改的服务器：
- 确定必须收集的数据。
- 确定必须收集数据的计算机
- 确定基础结构是否有 MCA 问题。
- 确定可从优化
MaxConcurrentApi值中受益的特定服务器。
有用的数据类型
下表列出了本文讨论的方法必须具有的数据类型。
| Data type | Source | 最适用于 |
|---|---|---|
| 错误消息 有关 Netlogon 日志和错误消息的详细信息 |
Netlogon 日志 | 识别 MCA 问题 |
| 服务器连接消息 | Netlogon 日志 | 确定哪些域控制器参与身份验证事务 |
| 事件 有关事件的详细信息 |
系统事件日志 Netlogon 日志 |
识别 MCA 问题 确定身份验证延迟的可能原因 |
| 性能计数器 有关 Netlogon 性能计数器的详细信息 |
性能监视器 Netlogon 日志 系统事件日志 |
识别 MCA 问题 优化 MCA 值 |
| 服务器到服务器事务详细信息，包括域控制器交互 如何启动和停止网络跟踪 |
netsh 网络监视器 |
确定哪些域控制器参与身份验证事务 确定身份验证延迟的可能原因 |
| 用户报告 | 用户 | 指示可能发生 MCA 问题 |
注意
此数据和数据源列表并不详尽。 其他数据类型和数据源，如 Windows 事件跟踪（ETW） 和 NTLM 操作事件日志，超出了本文的范围。
如何启动和停止网络跟踪
可以使用 Windows 本机 网络 shell （netsh） 工具收集网络跟踪。 若要开始跟踪，请在受影响的服务器上打开命令提示符窗口，然后输入以下命令：
netsh trace start capture=yes tracefile=c:\temp\<Filename>.etl
注意
在此命令中， <Filename> 表示存储跟踪数据的文件的名称。
若要停止跟踪，请使用启动跟踪时所用的同一帐户登录到服务器。 在命令提示符处，输入下列命令：
netsh trace stop
跟踪停止后，netsh 会在你提供的位置生成 ETL 和 CAB 文件。 可以使用 网络监视器 或消息分析器（已弃用，不再可供下载）查看文件。
有关 Netlogon 性能计数器的详细信息
Netlogon 性能计数器提供最精确的数据来优化MaxConcurrentApi值。
注意
- 性能监视器中的安全系统范围统计信息对象提供了多个与身份验证相关的计数器。 但是，它们不提供可以直接应用到
MaxConcurrentApi的数据。 - 其他性能计数器（如 CPU 和网络计数器）不会反映与
MaxConcurrentApi它相关的性能信息。
下表描述了最相关的计数器。 （在性能监视器，这些计数器属于 Netlogon 对象。“杂货店方案”是技术解释的更相关的版本。
| 性能计数器 | 技术说明 | 杂货店方案 |
|---|---|---|
| 信号灯持有者 | 持有信号灯的线程数。 此数字可以是 MaxConcurrentApi 当前配置值的任何值。 | 目前在收银机签出的人数。 |
| 信号灯等待程序 | 等待获取信号灯的线程数。 | 排队等候签出的人数。 |
| 信号灯超时 | 线程在等待信号灯时超时的总次数，该信号量在安全通道的生存期内测量（或自系统启动以来）。 | 放弃签出线的人总数，因为他们时间不足。 （如果该行更快，或者还有其他行，则可能不会发生。 |
| 平均信号灯保持时间 | 信号灯在最后一个样本中保存的平均时间（以秒为单位）。 | 每个人通过线路和签出的平均时间。 |
| 信号灯获取 | 信号灯在安全通道的生存期内获取的总次数（或自系统启动以来）。 | 成功签出的人员总数。 |
有关事件的详细信息
下表列出了与 MCA 问题关联的事件。 可以使用 事件查看器 或 Netlogon 日志文件来快速指示计算机是否存在 MCA 问题，从而找到这些事件。
| 事件源和 ID | 事件描述 | 相关的性能计数器 |
|---|---|---|
| Netlogon 5816 | Netlogon 在域<用户域 FQDN> 中失败了帐户<用户名>的身份验证请求。 请求在将请求发送到<域控制器直接受信任的域控制器 FQDN> 之前<超时，该域直接受信任的域名>。 这是第一次失败。 如果问题仍然存在，则会在几分钟>内记录有关每个事件日志频率的<合并事件。 | 信号灯超时 具有非零值。 身份验证请求失败。 |
| Netlogon 5817 | Netlogon 在最后<一次事件日志频率（以分钟>为单位）中失败了额外的<计数>身份验证请求。 请求在可以发送到<域控制器直接受信任的域控制器 FQDN>（直接受信任的域名>）<之前超时。 | 信号灯超时 具有非零值。 身份验证请求失败。 |
| Netlogon 5818 | Netlogon 在域用户域 FQDN 中通过域控制器直接信任的域控制器 <FQDN>><，对域<用户域 FQDN> 中的帐户<用户名>的身份验证请求花费了超过<警告事件阈值>秒。 这是第一个警告。 如果问题仍然存在，则会在几分钟内记录每个事件日志频率（ <以分钟> 为单位）定期事件。 | 信号灯等待程序 具有非零值。 身份验证请求正在放缓。 |
| Netlogon 5819 | Netlogon 在最后一<个事件日志频率（以分钟>为单位）中，通过<域控制器直接受信任的域控制器 FQDN>> <对身份验证请求计数>超过<警告事件阈值>秒。< | 信号灯等待程序 具有非零值。 身份验证请求正在放缓。 |
注意
Kerberos 事件 ID 7 可能指示 MCA 问题。 该事件具有以下说明：
Kerberos 子系统遇到 PAC 验证失败。 这表示领域客户端的 PAC 具有未验证或修改的 PAC。 请与系统管理员联系。
但是，MCA 问题以外的情况也可以触发此事件。
有关如何修改事件 ID 5816–5819 的日志记录频率和警告阈值的信息，请参阅 Windows Server 2008 R2 中跟踪 NTLM 身份验证延迟和失败的新事件日志条目。
有关 Netlogon 日志和错误消息的详细信息
在服务器上启用 Netlogon 日志记录时，Netlogon 服务将生成Netlogon.log和Netlogon.bak文件。 有关详细信息，请参阅 为 Netlogon 服务启用调试日志记录。 可以使用错误消息和事件在发生时识别 MCA 问题，确定哪些域控制器正在响应身份验证请求，并帮助识别问题计时的趋势。
可以使用文本编辑器查看日志文件。 如果Netlogon.bak文件可用，除了Netlogon.log文件外，还查看这些文件。 当身份验证请求因 MCA 问题而超时时，会看到类似于以下摘录的日志条目模式：
06/03 14:16:58 [LOGON] SamLogon: Network logon of <Domain>\User1 from WORKSTATION1 Entered
06/03 14:17:43 [CRITICAL] <Domain>: NlAllocateClientApi timed out: 0 258
06/03 14:17:43 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
06/03 14:17:43 [LOGON] SamLogon: Network logon of <Domain>\User1 from WORKSTATION1 Returns 0xC000005E
摘录的第一行记录身份验证请求。 第二行生成 45 秒后，记录超时。
注意
在典型的日志文件中，这两行之间可能有数百个无关的日志条目。
两条错误消息遵循超时行：
- 无法分配客户端 API 槽。 此消息是 MCA 问题的诊断。
- 网络登录...返回0xC000005E。 此消息始终附带上一条消息。 但是，其他问题也可以生成此消息，因此它本身不被视为诊断。
发生 MCA 问题时，Netlogon 日志也可能记录 Netlogon 事件（事件 ID 5816-5819）。
类似于以下示例的日志条目可帮助跟踪身份验证请求通过系统的路径：
12/25 01:39:03 [PERF] NlSetServerClientSession: Not changing connection (000000000A10FA48): "\\DC01.FAKEDOMAIN.LOCAL"
在何处开始查找问题
与任何瓶颈类似，环境（尤其是域拓扑和网络基础结构）会影响 MCA 问题本身的体现方式。 在一台服务器上发生的问题可能会导致其他服务器上的相关问题。 最有可能有 MCA 问题的服务器是域控制器和应用程序服务器（前端或后端服务器）。 工作站上很少出现 MCA 问题。
注意
如果知道由身份验证问题组成的用户和工作站，还可以查看工作站的详细 Netlogon 日志。 这些日志可能会提供问题见解。 但是，它们不太可能揭示问题的根本原因。
确定潜在的身份验证路径和阻塞点
身份验证路径是从基于 Netlogon 的身份验证请求遵循的一台服务器到下一个服务器的路径。 出于此讨论的目的，应用程序服务器首先接收请求。 请求将传送到完成身份验证的域控制器，并将响应返回到应用程序服务器。 但是，这是高度简化的视图。 该过程的详细信息取决于基础结构和域拓扑，以及其他因素。 此过程非常重要，因为若要识别 MCA 问题，必须分析来自可能处理身份验证请求的每个应用程序服务器和域控制器的数据。
重要
身份验证路径上的任何服务器都可能会创建一个阻塞点，其中 MCA 问题可能会降低身份验证请求的速度。 此外，多个服务器可能同时存在 MCA 问题。
当应用程序服务器必须对用户进行身份验证时，应用程序服务器首先尝试联系附近的域控制器（即在同一 Active Directory 逻辑站点中）。 如果同一站点中没有域控制器，应用程序服务器会将身份验证请求发送到本地域中可用的任何域控制器。 如果用户不是域的成员，则域控制器必须向其传递请求。 系统使用多个条件来确定请求的下一步位置：
- 如果域具有连接到另一个域的快捷方式信任或外部信任，路径中的下一个域控制器属于信任所指示的域。
- 如果域不是林根域，则下一个域控制器属于林根域。
- 如果用户不是林根域的成员，该域控制器将确定该用户是否属于同一林中的另一个域。
- 如果用户属于林中的另一个域，则下一个域控制器属于用户的域。
- 如果用户不属于林，请求将转到任何受信任林的根域旁边。
- 如果用户的域位于受信任的林中，该林的根域中的域控制器会将请求发送到用户域中的域控制器。
当路径中的最终域控制器对用户进行身份验证时，它将向应用程序服务器返回身份验证响应。 响应遵循与请求相同的路径，但相反。
重要
使用Active Directory 域服务（AD DS）集成的 DNS 时，AD DS 站点拓扑可以简化或使身份验证路径复杂化。 域控制器的 DNS 记录包含站点信息。 因此，当域控制器查询 DNS 以在目标域中查找域控制器时，它实际上可能会发送两个 DNS 查询，如下所示：
- 第一个查询请求属于目标域中同一 AD DS 站点的域控制器列表。
- 如果第一个请求失败，域控制器再次查询以获取目标域中所有域控制器的列表。
在任一情况下，列表中的任一域控制器都可能会收到身份验证请求。 选择算法不考虑其他因素，例如连接速度。 在复杂的拓扑中，站点可以将可能的身份验证路径限制为具有高容量连接的域控制器的选定子集。
有关在多个林中使用站点名称时 Windows 如何定向身份验证请求的详细信息，请参阅 跨林信任的域定位符。
有关 Active Directory 集成 DNS 的详细信息，请参阅 查看 DNS 概念。
下图概述了确定身份验证路径的条件。
有关如何识别身份验证路径和潜在阻塞点的示例
以下示例演示如何标识应检查 MCA 问题的服务器。
示例 1：单林拓扑
请考虑以下拓扑。
域 B 服务用户来自域 C 并使用 NTLM 身份验证的 Web 服务器。 域 B 和域 C 位于同一林中。 域 A 是林根域。
每当用户访问 Web 服务器资源时，身份验证请求都会执行以下步骤：
Web 服务器接收身份验证请求，然后将其发送到“附近”域控制器（Web 服务器域中同一逻辑站点中的域控制器）。
如果同一站点中没有域控制器，Web 服务器会将请求重新发送给域 B 中的任何域控制器。
域 B 域控制器确定用户不在域 B 中，并将身份验证请求传递到林根目录（域 A）。
同样，域 B 域控制器首先尝试将请求发送到同一站点中的域控制器，如果这不起作用，它将请求发送到域 A 中的任何可用域控制器。
域 A 域控制器确定用户不属于域 A，但属于同一林中的域 C。 它将请求发送到域 C（同一站点域控制器或域中的任何域控制器）。
域 C 域控制器对用户进行身份验证，然后发送身份验证响应。
若要完成身份验证过程，响应会沿着同一链返回到域 B 中的 Web 服务器。
根据站点拓扑，以下服务器是潜在的窒息点。
| 路径段 | 在一个站点内发送和接收服务器 | 在不同站点中发送和接收服务器 |
|---|---|---|
| 1 | Web 服务器 站点中的域 B 域控制器 |
Web 服务器 所有域 B 域控制器 |
| 2 | 站点中的域 A 域控制器 | 所有域 A 域控制器 |
| 3 | 站点中的域 C 域控制器 | 所有域 C 域控制器 |
示例 2：简单的双林拓扑
请考虑以下拓扑：
域 A 是林 A 的根域，域 D 是林 B 的根域。域 A 和 B 具有林信任。
域 B 和 C 属于林 A，域 E 和 F 属于林 B。域 B 中的 Web 服务器使用 NTLM 身份验证为域 E 中的用户提供服务。
域 B 服务用户来自域 E 并使用 NTLM 身份验证的 Web 服务器。 域 B 是域 A（林根）的子域，域 A 包含域 D 的林信任，其中包含域 E（包含用户帐户的子域）。
每次用户访问 Web 服务器资源时，身份验证请求都遵循以下步骤：
Web 服务器接收身份验证请求，然后将其发送到“附近”域控制器（Web 服务器域中同一逻辑站点中的域控制器）。
如果同一站点中没有域控制器，Web 服务器会将请求重新发送给域 B 中的任何域控制器。
域 B 域控制器确定用户不在域 B 中。它将身份验证请求传递到林根目录（域 A）。
同样，域 B 域控制器首先尝试将请求发送到同一站点中的域控制器。 如果这不起作用，域 B 域控制器会将请求发送到域 A 中的任何可用域控制器。
域 A 域控制器确定用户不属于域 A，并且用户的域不在林 A 中。它将跨林信任的身份验证请求转发到域 D（同一站点域控制器或域中的任何域控制器）。
域 D 域控制器确定用户不属于域 D，但属于同一林中的域 E。 它将请求发送到域 E（同一站点域控制器或域中的任何域控制器）。
域 E 域控制器对用户进行身份验证，然后发送身份验证响应。
若要完成身份验证过程，响应会沿着同一链返回到域 B 中的 Web 服务器。
根据站点拓扑，以下服务器是潜在的窒息点：
| 路径段 | 在一个站点内发送和接收服务器 | 在不同站点中发送和接收服务器 |
|---|---|---|
| 1 | Web 服务器 站点中的域 B 域控制器 |
Web 服务器 所有域 B 域控制器 |
| 2 | 站点中的域 A 域控制器 | 所有域 A 域控制器 |
| 3 | 站点中的域 D 域控制器 | 所有域 D 域控制器 |
| 4 | 站点中的域 E 域控制器 | 所有域 E 域控制器 |
示例 3：内部/外部林拓扑
请考虑以下拓扑。
域 A 和域 D 具有外部信任。 域 A 服务中的 Web 服务器来自域 D，并使用 NTLM 身份验证。
注意
这是适用于快捷方式信任的相同方法。
每当用户访问 Web 服务器资源时，身份验证请求都会执行以下步骤：
Web 服务器接收身份验证请求，然后将其发送到“附近”域控制器（Web 服务器域中同一逻辑站点中的域控制器）。 如果同一站点中没有域控制器，Web 服务器会将请求重新发送给域 A 中的任何域控制器。
域 A 域控制器确定用户不属于域 A。它将身份验证请求跨外部信任转发到域 D（同一站点域控制器或域中的任何域控制器）。
域 D 域控制器对用户进行身份验证，然后发送身份验证响应。
若要完成身份验证过程，响应会沿着同一链返回到域 A 中的 Web 服务器。
根据站点拓扑，以下服务器是潜在的窒息点。
| 路径段 | 在一个站点内发送和接收服务器 | 在不同站点中发送和接收服务器 |
|---|---|---|
| 1 | Web 服务器 站点中的域 A 域控制器 |
Web 服务器 所有域 A 域控制器 |
| 2 | 站点中的域 E 域控制器 | 所有域 E 域控制器 |
快速参考：不同方案中的潜在窒息点
此表介绍搜索准则在更通用的范围中可能存在的窒息点。 查看表时，请记住，在前端/后端配置中，前端和后端应用程序服务器都是潜在的阻塞点。 同样，必须在负载均衡的服务器组的所有成员上收集数据。
单个林方案
| 示例瓶颈方案 | 可能的窒息点（收集数据的位置） |
|---|---|
| 为同一域中的用户发送凭据的应用程序服务器 方案详细信息：
|
|
| 为不同直接受信任的域中的用户发送凭据的应用程序服务器（具有林根的非传输性外部信任或可传递信任）* 方案详细信息：
|
|
| 为不同子域中的用户发送凭据的应用程序服务器（在同一林中） 方案详细信息：
|
|
* 这是示例 2 中所述 的方案：简单的双林拓扑。
多林方案
| 示例瓶颈方案 | 可能的窒息点（收集数据的位置） |
|---|---|
| 子域中的应用程序服务器为不同林根目录中的用户发送凭据（通过林信任） 方案详细信息：
|
|
| 子域中的应用程序服务器为不同林的子域中的用户发送凭据（通过林信任）* 方案详细信息：
|
|
| 稍微复杂一些的情况... 子域中的前端/后端应用程序服务器配置（如 Microsoft Exchange），用于为不同林的子域中的用户发送凭据（通过林信任） 方案详细信息：
|
|
初步调查：是否存在 MCA 问题？
确定基础结构中潜在的阻塞点后，可以开始收集和分析数据。 第一个优先级是确定 MCA 问题是否确实存在。 稍后，请精确缩小哪个服务器（或服务器）有问题。
重要
若要收集数据，请为在上一部分标识的所有窒息点启用 Netlogon 日志记录。 如果你有许多潜在的窒息点，请查看本部分和下一部分， 缩小范围并确定趋势。
若要识别 MCA 问题，必须在服务器负载过大时收集性能数据。 当服务器看到大多数客户端请求时，会发生大量负载。 例如，在电子邮件服务器方案中，收集性能数据的最佳时机是用户到达工作并检查其电子邮件。 因此，必须确保给定方案中的所有服务器在忙于处理大量负载时查看其性能数据。
快速扫描：性能计数器和事件日志
Netlogon 性能计数器和事件日志提供问题是否存在的概览视图。 还可以确定问题是否位于提供数据的服务器或位于同一站点或域中的另一台服务器上。
为了帮助解释计数器值，请检查提供数据的服务器是否已具有非默认 MaxConcurrentApi 值。 为此，请按照下列步骤进行操作：
选择“开始”，输入 regedit，然后在搜索结果中选择注册表编辑器。
转到以下注册表子项：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\MaxConcurrentApiMaxConcurrentApi如果密钥不存在，则可以安全地假定计算机使用默认值MaxConcurrentApi。 默认值如下：- 域控制器和成员服务器（Windows Server 2012 及更高版本）： 10
- 客户端计算机和工作站（Windows 8 及更高版本）： 1
注意
客户端计算机和工作站很少使用大于 1 的值。
下表列出了一台计算机上可能一起看到的事件和计数器值，以及每个组合的重要性。
| 事件 | 计数器值 | 含义 |
|---|---|---|
| 空值 | 信号灯持有者 等于本地服务器上当前配置的 MCA 设置。 | 本地服务器（或同一级别的另一台服务器）可能有 MCA 问题。 |
| 5816 5817 |
信号灯超时 值非零 | 正在发生身份验证超时。 本地服务器可能存在 MCA 问题。 |
| 5818 5819 |
信号灯等待程序 具有一个非零值，该值会持续任何时间长度 –和– 信号灯持有者 的值小于本地服务器上的 MCA 设置 |
身份验证链中的不同服务器上可能存在 MCA 问题。 |
快速扫描：Netlogon 日志文件
若要使用 Netlogon 日志文件标识 MCA 问题，请搜索文件。Can't allocate client API slot 可以使用文本编辑器（如记事本、脚本或命令行命令）执行此操作。 使用不区分大小写的搜索。 如果此字符串出现在日志文件中，则会出现 MCA 问题。
例如，如果将netlogon.log和netlogon.bak存储在 c：\temp 文件夹中，则可以打开命令提示符窗口并运行以下命令：
Find /I "Can't allocate client API slot" c:\temp\netlogon.log > c:\temp\MCA-detect-sample.txt
Find /I "Can't allocate client API slot" c:\temp\netlogon.bak >> c:\temp\MCA-detect-sample.txt
如果日志文件包含字符串，则结果文件 MCA-detect-sample.txt包含类似于以下摘录的文本：
---------- C:\temp\NETLOGON.LOG
[3]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[5]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[7]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[10]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[12]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[17]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
[19]12/25 07:12:02 [CRITICAL] <Domain>: NlpUserValidateHigher: Can't allocate Client API slot.
注意
在此摘录中， <域> 表示响应身份验证请求的域。
如果在特定服务器上找不到任何匹配项，请搜索文件以查找 0xC000005E。 此错误代码指示身份验证请求超时。它还可能指示处理身份验证请求的其他计算机之一出现 MCA 错误。 使用此信息确定下一步要检查的计算机。 如果要处理大量服务器，请参阅下一部分，了解如何缩小分析范围。
缩小范围并确定趋势
本部分提供了帮助处理许多潜在窒息点的提示。
若要有效使用 MaxConcurrentApi ，必须查明要缓解的特定服务器。 从长远来看，必须了解为什么这些特定服务器过载。 使用该信息，可以改进拓扑，使其不再需要 MaxConcurrentApi 调整（本系列的第 3 部分所述）。
注意
可以使用记事本或Microsoft Excel 等应用程序对日志文件进行排序和搜索。
查找如下趋势：
Netlogon 日志包括可用于标识身份验证路径中涉及的域控制器的连接消息。 此类日志条目类似于以下摘录：
12/25 01:39:03 [PERF] NlSetServerClientSession: Not changing connection (000000000A10FA48): "\\DC01.CONTOSO.LOCAL"确定服务器尝试连接到的域控制器时，请检查请求是否实际到达其中一个域控制器。
例如，假设在应用程序服务器日志中发现
Can't allocate client API slot错误。 此类错误表示应用程序服务器本身存在 MCA 问题。 仔细检查应用程序服务器尝试联系的任何域控制器。 如果应用程序服务器是问题的根目录，则域控制器可能从未收到请求。使用 Netlogon 日志和网络跟踪（以及潜在的性能计数器）中的时间戳来比较身份验证路径中每个“跃点”的速度。
例如，请考虑在单个林中的两个子域之间传输的身份验证请求。 将请求从请求子域传递到根域所需的时间明显短于从根域传递到目标子域所需的时间。 在这种情况下，某些内容可能会延迟根域控制器或目标（子）域控制器上的请求。
检查哪些用户受到影响，以及何时受到影响。 来自同一域或林的所有受影响的用户是否？ 此问题是否仅影响特定用户或所有用户？ 一天中的时间是否有所作为？ 可以使用类似于以下摘录的 Netlogon 日志条目来跟踪特定用户的请求：
[8]12/25 07:12:02 [LOGON] SamLogon: Network logon of CONTOSO\User1 from WIN7CLIENT1 Returns 0xC000005E[3905][29654]12/25 07:16:03 [LOGON] SamLogon: Network logon of CONTOSO\User1 from WIN7CLIENT1 Returns 0xC000005E
示例：使用性能监视器搜索 MCA 问题
作为实际示例，请考虑运行 IIS 和 FTP 的应用程序服务器中的性能监视器数据（BLG）文件，并提供文件和打印服务器功能。 问题出现后几个小时，数据文件就会启动。 对于此示例，假设生成此数据的服务器是环境中唯一怀疑存在 MCA 问题的服务器。
Performance Manager 中的以下视图显示了 110 秒的数据段。
身份验证请求是否超时？
首先，使用信号灯超时计数器的数据来计算在此时间间隔内发生的信号量超时数。 此计数器是累积的。 因此，持续时间开头的值是最小值，持续时间末尾的值是最大值。 从最大超时次数中减去最小超时数，将在此间隔内产生 2,253 次超时值。 此计数器的预期值为零。 显然，此处存在 MCA 问题。
延迟的请求量是多少？
在同一间隔内查看信号灯等待程序计数器的数据。 此计数器跟踪正在等待但尚未超时的请求。此信息可以指示问题的大小。
在这种情况下，在此时间间隔内最多存在 2,157 个“服务员”。
结束语
我们的示例服务器存在严重的身份验证超时问题。 本系列的第 2 部分将继续本示例，演示如何计算 MaxConcurrentApi 此服务器的值。