如何使用 MaxConcurrentApi 设置对 NTLM 身份验证进行性能优化

本文介绍如何使用 MaxConcurrentApi 设置对 NTLM 身份验证进行性能优化。

适用于: Windows Server 2012 R2
原始 KB 编号: 2688798

简介

企业信息技术消费化程度 (面向消费者的设备(如企业企业) 中使用的智能手机和平板电脑)的增多,导致企业在其企业环境中可能经历旧式身份验证大幅增加的方案数量增加。 旧式身份验证的这种增加可能会导致性能问题,例如客户端的延迟或超时。

在环境中发现身份验证超时或延迟 (也称为 MaxConcurrentApi 瓶颈) 时,解决此问题的典型方法是提高为该身份验证提供服务的最大允许工作线程数。 为此,可以更改 MaxConcurrentApi 注册表值,然后在服务器上重启 Net Logon 服务。

识别哪些服务器是瓶颈的受害者以及哪些服务器实际上是瓶颈延迟的根源可能很困难。 本文介绍如何使用 MaxConcurrentApi 设置对 NT LAN Manager (NTLM) 身份验证执行性能优化。 本文包含管理员在确定要对其上调 MaxConcurrentApi 值的服务器以及应设置该值的数量时的指导。

解决方案

重要

此部分(或称方法或任务)介绍了修改注册表的步骤。 但是,注册表修改不当可能会出现严重问题。 因此,请务必严格按照这些步骤操作。 为了加强保护,应先备份注册表,再进行修改。 如果出现问题,可以还原注册表。 有关如何备份和还原注册表的更多信息,请单击下面的文章编号查看 Microsoft 知识库中相应的文章:
322756 如何在 Windows 中备份和还原注册表

若要解决此问题,必须查看从方案中涉及的所有服务器获取的性能数据。 然后,可以尝试增加那些显示性能损失的服务器上的 MaxConcurrentApi 设置。

存在 Netlogon 报告 NTLM 身份验证问题的可用事件,请参阅:
2654097 Windows Server 2008 R2 中跟踪 NTLM 身份验证延迟和失败的新事件日志条目可用

事件指示两个计数器的活动:

  • 事件 5818/5819:如果启用了事件,则存在“信号灯等待者”。
  • 事件 5816/5817:存在“信号灯超时”。

为了确定服务器的最佳 MaxConcurrentApi 值,必须使用公式将多个数据点组合在一起并计算。 用于估计 MaxConcurrentApi 的数据如下所示:

  • Net Logon 信号灯获取
  • Net Logon 信号灯超时
  • Net Logon 平均信号灯保持时间
  • 完成的性能日志记录持续时间(以秒为单位)

获取数据后,以下公式可用于估计正确的 MaxConcurrentApi 值: (semaphore_acquires + semaphore_time输出) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
从服务器在身份验证负载下收集 Net Logon 性能数据后,应通过查看行视图开始和结束时间来确定数据收集过程的持续时间。

注意

占位符 semaphore_acquiressemaphore_time输出 表示在安全通道生存期内发生的超时数的累积数字。 因此,在收集的数据中,数字很可能不会从零开始。 在 Perfmon.msc 性能监视器 (中使用行视图时,必须从结束数字中减去起始编号) 。 然后,在公式中为新的 MaxConcurrentApi 设置使用此计算数字。 若要确定数据收集期间发生的超时数,请使用 Perfmon.msc 中的“行视图”,将鼠标指针停留在末尾和开始处该计数器的行上,然后从结束数字中减去起始数字。 该结果是要放入公式中的数字。

可以通过在 Perfmon.msc 中将默认视图从“线条视图”更改为“报表视图”来确定平均信号灯保持时间。 例如,请考虑以下情况。

  • 信号灯获取值为 8,286。
  • 信号灯超时值为 883。
  • 平均信号灯保持时间 (.5 即半秒) 。
  • 报告的持续时间为 90 秒。

在此方案中,公式将如下所示:
(8,286 + 883) *.5 / 90 =< 51

如果从公式派生的值为 150 或更大,则应添加更多服务器来为旧式身份验证负载提供服务。

如果值小于 150,则应将该服务器上的 MaxConcurrentApi 注册表值更改为公式建议的值或更大的值。

注意

如果决定将 MaxConcurrentApi 值增加到大于 10,则应在非生产环境中测试所需设置的负载和性能,然后再在生产环境中实现更改。 建议这样做,以确保增加此值不会导致其他资源瓶颈。 此外,请注意,负载条件可能会根据每个方案和业务环境而更改。 因此,如果服务负载发生更改,则 MaxConcurrentApi 值在以后可能必须具有不同的设置。

若要更改 MaxConcurrentApi 设置,请执行以下步骤:

  1. 单击“开始”,单击“运行”,键入 regedit,然后单击“确定”

  2. 找到并单击以下注册表子项:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. 在“编辑”菜单上,指向“新建”,然后单击“DWORD 值”

  4. 键入 MaxConcurrentApi,然后按 Enter。

  5. “编辑”菜单上,单击“修改”

  6. 在 decimal 中键入新的 MaxConcurrentApi 设置,然后单击“ 确定”。

  7. 在命令提示符下,键入以下命令,然后按 Enter:
    net stop netlogon

  8. 键入以下命令,然后按 Enter:
    net start netlogon

更多信息

可以使用以下知识库文章来更详细地识别旧式身份验证瓶颈的客户端症状:
975363 连接到经过身份验证的服务时,系统会间歇性地提示你提供凭据或体验超时。在这种情况下,身份验证瓶颈可能位于多台服务器上。 因此,必须确保给定方案中的所有服务器在忙于处理繁重负载时都查看其性能数据。

必须在处理客户端请求所涉及的所有应用程序服务器、域控制器和受信任的域控制器上查看信号灯获取、信号量超时和平均信号量保持时间的计数器。

当服务器负载过重时,必须跟踪性能数据。 当服务器看到最多的客户端请求时,会出现负载过重的情况。 例如,在电子邮件服务器方案中,收集性能数据的最佳时机是用户到达工作并检查其电子邮件。

其他注意事项如下:

  • 没有值意味着不需要执行任何操作。 信号 灯持有者信号灯保持时间 计数器将不会显示任何值,除非服务器上存在持续负载。 如果没有值,则无需更改 MaxConcurrentApi 值。

  • 一个大小不适合所有大小。 对于每个服务器,MaxConcurrentApi 值可能必须是不同的值。 这种情况的原因可能是多个应用程序服务器从单个域控制器获取身份验证,或者多个服务器提供域控制器必须处理的更大负载量的类似方案。

  • 信托。 如果要进行身份验证的用户来自受信任的域,则可能会导致更长的延迟,因为本地域控制器必须等待受信任的域控制器的回复,然后本地域控制器才会向应用程序服务器提供响应。

  • 网络延迟。 网络延迟也可能在导致 MaxConcurrentApi 瓶颈方面起主要作用。 当 MaxConcurrentApi 信号灯使用基于时间的超时计数器,以便客户端不会无限期地等待旧式身份验证时,可能会出现此问题。

  • 搭配。 如果存在网络延迟,并且导致完成 MaxConcurrentApi 线程时出现延迟和瓶颈,则常见的解决方案是将服务器置于同一物理位置,以便降低网络延迟。 例如,在受信任的域具有 Microsoft Exchange CAS 服务器的域模型中,并且用户的域位于另一个区域或 Active Directory 站点中,这意味着将用户的域控制器置于与 Exchange CAS 服务器及其域控制器相同的物理位置和 Active Directory 站点中。

  • 可能的下游延迟。 如果 信号灯 Waiters 计数器值始终大于 0 (零) ,并且 信号灯持有者 值小于该服务器上的 MaxConcurrentApi 设置,则瓶颈不位于该服务器上。 在这种情况下,请查看计数器名称中引用的域控制器,该名称被列为主计算机完全限定的域名。 应查看域控制器的信号灯等待者和信号灯持有者性能数据。

  • 负载或网络配置中的更改。 将来对正在提供服务的负载或网络配置中的更改可能会产生网络延迟,并可能导致需要再次测量正确的 MaxConcurrentApi 设置。 对于正在检查 MaxConcurrentApi 设置的旧身份验证卷的环境,我们强烈建议你持续监视和查看 Net Logon 性能对象计数器。 可以通过使用计划的自定义 Perfmon.msc 数据收集器、Microsoft System Center Operations Manager 或其他方法执行此操作。

  • Windows Server 2008 最大值。 在 Windows Server 2008 和更高版本的 Windows 中,MaxConcurrentApi 允许的最大设置为 150。 如果正在使用的服务器未运行 Windows Server 2008 R2,请应用以下知识库文章中所述的修补程序,以获得最大 150 个可用设置:
    975363 连接到经过身份验证的服务时,系统会间歇性提示输入凭据或出现超时

  • Windows Server 2003 最大值。 Windows Server 2003 和早期版本中 MaxConcurrentApi 允许的最大设置为 10。

  • Windows Server 2012和更新的默认值。 maxConcurrentApi 的默认值已在 Windows Server 2012 中更改。 成员服务器和域控制器为 10。 对于成员工作站,它仍为 1。

  • Windows Server 2003 和性能计数器。 Windows Server 2003 的原始版本不包含 Net Logon 性能计数器。 可以应用修补程序来添加它。

如果想要减少总体 NTLM 身份验证负载,从而最终减少 MaxConcurrentApi 信号灯的使用数量,则识别执行重复和连续 NTLM 身份验证的未授权或未知客户端或服务可能很有用。 可以通过使用 Net Logon 服务调试日志记录来识别以这种方式进行的重复身份验证。 有关如何使用 Netlogon.log 文件调试 Net Logon 服务的详细信息,请单击以下序列号以查看 Microsoft 知识库中的文章:
109626 启用 Net Logon 服务的调试日志记录

Security System-Wide Statistics 对象下 NTLM 身份验证的 Perfmon.msc 计数器不是 MaxConcurrentApi 跟踪线程的使用次数的反映。 Net Logon 性能计数器中显示的 MaxConcurrentApi 信号灯使用情况与 NTLM 身份验证计数器递增之间没有一对一关联。 NTLM 身份验证计数器在确定最佳 MaxConcurrentApi 值时无用。

此外,与 MaxConcurrentApi 相关的旧式身份验证性能超时很可能会显示,但不会反映在除 Net Logon 计数器以外的任何性能计数器中。 这意味着,即使 MaxConcurrentApi 负载很重且用户遇到问题,其他性能指标(如 CPU 使用率和磁盘和网络使用情况)也可能显示无负载。

可以对在其 Net Logon 服务调试日志中具有条目的域控制器执行额外的最小化过程,这些条目指示客户端正在 <null>\username 提交而不是 domainname\username。 Microsoft 知识库中的以下文章介绍了此过程:
923241 如果 Active Directory 域控制器上存在许多外部信任,Lsass.exe 进程可能会停止响应