Настройка производительности для проверки подлинности NTLM с помощью параметра MaxConcurrentApi

  • Статья

В этой статье описывается настройка производительности для проверки подлинности NTLM с помощью параметра MaxConcurrentApi.

Применяется к: Windows Server 2012 R2
Исходный номер базы знаний: 2688798

Введение

Рост потребительства корпоративных информационных технологий (увеличение числа ориентированных на потребителя устройств, таких как смартфоны и планшеты, используемые в корпоративном предприятии) привел к увеличению числа сценариев, в которых предприятия могут столкнуться с большим увеличением устаревшей проверки подлинности в своих корпоративных средах. Это увеличение устаревшей проверки подлинности может привести к проблемам с производительностью, например задержкам или истечению времени ожидания для клиентов.

Когда вы обнаруживаете время ожидания или задержки проверки подлинности (также известные как узкие места MaxConcurrentApi) в среде, типичным способом решения проблемы является создание максимально допустимых рабочих потоков, обслуживающих эту проверку подлинности. Это можно сделать, изменив значение реестра MaxConcurrentApi, а затем перезапустив службу сетевого входа на серверах.

Определить, какие серверы являются жертвами узкого места, а какие серверы фактически являются источником задержек узких мест, может быть трудно. В этой статье описывается настройка производительности для проверки подлинности NT LAN Manager (NTLM) с помощью параметра MaxConcurrentApi. В этой статье содержатся рекомендации для администраторов по определению серверов, на которых требуется поднять значение MaxConcurrentApi, и суммы, в которую необходимо установить это значение.

Разрешение

Важно!

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о создании резервной копии и восстановлении реестра см. в соответствующей статье базы знаний Майкрософт:
322756 Создание резервной копии и восстановление реестра Windows

Чтобы устранить эту проблему, необходимо просмотреть данные о производительности, взятые со всех серверов, участвующих в сценарии. Затем можно попытаться увеличить параметр MaxConcurrentApi на тех серверах, на которых показана потеря производительности.

Доступны Netlogon события, сообщающие о проблемах проверки подлинности NTLM, см. следующие статьи:
2654097 Доступны новые записи журнала событий, отслеживающие задержки и сбои проверки подлинности NTLM в Windows Server 2008 R2.

События указывают действие для двух счетчиков:

  • События 5818/5819: если события включены, существуют "Семафор официанты".
  • События 5816/5817: "Время ожидания Семафора".

Чтобы определить лучшее значение MaxConcurrentApi для серверов, необходимо объединить несколько точек данных и вычислить их с помощью формулы. Для оценки MaxConcurrentApi используются следующие данные:

  • Получение семафора net Logon
  • Время ожидания семафора net logon
  • Среднее время удержания семафора net Logon
  • Длительность завершения ведения журнала производительности, измеряемая в секундах

После получения данных можно использовать следующую формулу для оценки правильного значения MaxConcurrentApi:(semaphore_acquires + semaphore_time outs) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
После сбора данных о производительности сетевого входа с момента, когда сервер был под нагрузкой проверки подлинности, следует определить длительность процесса сбора данных, просмотрев время начала и окончания представления строк.

Примечание.

Заполнители semaphore_acquires и semaphore_time outs представляют собой совокупные числа, указывающие, сколько тайм-аутов произошло за время существования канала безопасности. Таким образом, числа, скорее всего, не будут начинаться с нуля в собираемых данных. Начальная цифра должна быть вычитана из конечного числа при использовании представления строки в Монитор производительности (Perfmon.msc). Затем это вычисляемое число используется в формуле для нового параметра MaxConcurrentApi. Чтобы определить количество тайм-аутов, возникших во время сбора данных, используйте представление строки в Perfmon.msc и наведите указатель мыши на строку для этого счетчика в конце и начале, а затем вычесть начальную цифру из конечного числа. Этот результат — это число, которое нужно поместить в уравнение.

Среднее время удержания семафора можно определить, изменив представление по умолчанию с представления строки на представление отчета в Perfmon.msc. Рассмотрим, например, описанный ниже сценарий.

  • Значение семафора равно 8286.
  • Время ожидания семафора равно 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 и нажмите клавишу ВВОД.

  5. В меню Правка щелкните Изменить.

  6. Введите новый параметр MaxConcurrentApi в десятичном формате и нажмите кнопку ОК.

  7. В командной строке введите следующую команду и нажмите клавишу ВВОД:
    net stop netlogon

  8. Введите следующую команду и нажмите клавишу ВВОД:
    net start netlogon

Дополнительная информация

Для более подробного определения симптомов устаревших узких мест проверки подлинности на стороне клиента можно использовать следующую статью базы знаний:
975363 При подключении к службам с проверкой подлинности периодически запрашиваются учетные данные или время ожидания при подключении к службам, прошедшим проверку подлинности. В этом сценарии узкое место проверки подлинности может быть на нескольких серверах. Поэтому необходимо убедиться, что все серверы в данном сценарии проверяют данные о производительности, пока они заняты обслуживанием больших нагрузок.

Счетчики для получения семафора, времени ожидания семафора и среднего времени удержания семафора должны проверяться на всех серверах приложений, контроллерах домена и доверенных контроллерах домена, участвующих в обслуживании клиентских запросов.

Данные о производительности должны отслеживаться, пока серверы находятся под большой нагрузкой. Большая нагрузка возникает, когда серверы видят больше всего клиентских запросов. Например, в сценарии с сервером электронной почты лучше всего собирать данные о производительности, когда пользователи приходят на работу и проверка свои сообщения электронной почты.

Ниже приведены дополнительные элементы, которые следует рассмотреть.

  • Нет значений, означают, что никаких действий не требуется. Счетчики держателей семафоров и времени удержания семафора не будут отображать значения, если на сервер не будет постоянной нагрузки. Если значения отсутствуют, изменение значения MaxConcurrentApi не требуется.

  • Один размер не подходит для всех. Значение MaxConcurrentApi может быть разным для каждого сервера. Эта ситуация может быть вызвана тем, что несколько серверов приложений получают проверку подлинности от одного контроллера домена или аналогичные сценарии, в которых несколько серверов обеспечивают больший объем нагрузки, с которой должен работать контроллер домена.

  • Доверяет. Если пользователи, прошедшие проверку подлинности, являются доверенными доменами, это может привести к более длительным задержкам, так как локальный контроллер домена должен дождаться ответа от доверенного контроллера домена, прежде чем локальный контроллер домена предоставит ответ серверу приложений.

  • Задержка в сети. Задержка сети также может играть важную роль в возникновении узких мест MaxConcurrentApi. Эта проблема может возникнуть, когда семафор MaxConcurrentApi использует счетчик времени ожидания на основе времени, чтобы клиенты не ждали проверки подлинности устаревших версий.

  • Коллокации. Если задержка в сети существует и вызывает задержки и узкие места при завершении потоков MaxConcurrentApi, распространенное решение заключается в том, чтобы разместить серверы в том же физическом расположении, чтобы уменьшить задержку в сети. В модели домена, в которой доверенный домен имеет серверы microsoft Exchange CAS, а домен пользователя находится в другом регионе или на сайте Active Directory, это означает, что контроллеры домена пользователя помещают в то же физическое расположение и сайт Active Directory, что и серверы Exchange CAS и их контроллеры домена.

  • Возможная задержка нижестоящего потока. Если значение счетчика Semaphore Waiters постоянно превышает 0 (ноль) в течение любого времени, а значение держателей Семафора меньше параметра MaxConcurrentApi на этом сервере, узкое место не находится на этом сервере. В этом случае найдите контроллер домена, который указан в имени счетчика, который указан как полное доменное имя главного компьютера. Данные о производительности semaphore Waiters и Semaphore Holders контроллера домена должны быть проверены.

  • Изменения в загрузке или в конфигурации сети. Будущие изменения в обслуживаемой нагрузке или в конфигурациях сети могут привести к задержке сети и могут привести к необходимости повторного определения правильного параметра MaxConcurrentApi. Для сред, в которых устаревший том проверки подлинности просматривается в той степени, в которой проверяются параметры MaxConcurrentApi, настоятельно рекомендуется постоянно отслеживать и проверять счетчики объектов производительности Net Logon. Это можно сделать с помощью запланированных пользовательских сборщиков данных Perfmon.msc, с помощью Microsoft System Center Operations Manager или с помощью других методов.

  • Windows Server 2008 maximum. Максимально допустимый параметр MaxConcurrentApi в Windows Server 2008 и более поздних версиях Windows — 150. Примените исправление, описанное в следующей статье базы знаний, чтобы иметь максимальное доступное значение 150, если сервер, который вы используете, не работает под управлением Windows Server 2008 R2:
    975363 при подключении к службам, прошедшим проверку подлинности, периодически запрашиваются учетные данные или время ожидания.

  • Максимум Windows Server 2003. Максимально допустимый параметр MaxConcurrentApi в Windows Server 2003 и более ранних версиях — 10.

  • Windows Server 2012 и более новых значений по умолчанию. Значение по умолчанию для MaxConcurrentApi было изменено в Windows Server 2012. Он равен 10 для рядовых серверов и контроллеров домена. Он остается на уровне 1 для рабочих станций-членов.

  • Windows Server 2003 и счетчики производительности. Исходный выпуск Windows Server 2003 не содержал счетчиков производительности Net Logon. Вы можете применить исправление, чтобы добавить его.

Выявление несанкционированных или неизвестных клиентов или служб, выполняющих повторяющуюся и непрерывную проверку подлинности NTLM, может оказаться полезным, если требуется уменьшить общую нагрузку на проверку подлинности NTLM и, следовательно, уменьшить количество использованных семафоров MaxConcurrentApi. Повторяющуюся проверку подлинности таким образом можно определить с помощью ведения журнала отладки службы net Logon. Чтобы получить дополнительные сведения об использовании файла Netlogon.log для отладки службы net Logon, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
109626 Включение ведения журнала отладки для службы "Сетевой вход"

Счетчик Perfmon.msc для проверки подлинности NTLM в объекте Security System-Wide Statistics не отражает количество использования отслеживаемого потока MaxConcurrentApi. Не существует корреляции "один к одному" между использованием семафора MaxConcurrentApi, которое отображается в счетчике производительности Net Logon и счетчике проверки подлинности NTLM. Счетчик проверки подлинности NTLM не полезен при определении наилучшего значения MaxConcurrentApi.

Кроме того, вполне вероятно, что устаревшие время ожидания производительности проверки подлинности, связанные с MaxConcurrentApi, будут отображаться, но не отражаются ни в одном счетчике производительности, кроме счетчика сетевого входа. Это означает, что другие метрики производительности, такие как использование ЦП и использование дисков и сети, могут не показывать нагрузку, даже если нагрузка MaxConcurrentApi является высокой и пользователи имеют проблемы.

Дополнительную процедуру минимизации можно выполнить на контроллерах домена с записями в журнале отладки службы net Logon, указывающими, что клиенты отправляют <null>\username вместо domainname\username. Эта процедура описана в следующей статье базы знаний Майкрософт:
923241 . Процесс Lsass.exe может перестать отвечать на запросы при наличии большого количества внешних доверительных отношений на контроллере домена Active Directory