Поделиться через

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

  • Статья

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

Исходный номер базы знаний: 2688798

Введение

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

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

Определение того, какие серверы являются жертвами узких мест и какие серверы на самом деле являются источником задержек узких мест, может быть трудно. В этой статье описывается, как настроить производительность для проверки подлинности 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 semaphore получает
  • Время ожидания семафора для net Logon
  • Среднее время хранения семафора net Logon
  • Длительность ведения журнала производительности, которая завершена, измеряется в секундах

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

Примечание.

Заполнители semaphore_acquires и semaphore_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 и нажмите клавишу ВВОД.

  5. В меню "Изменить" нажмите кнопку "Изменить".

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

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

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

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

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

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

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

Дополнительные элементы для рассмотрения приведены следующим образом:

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

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

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

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

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

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

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

  • Максимум Windows Server 2008. Максимальное значение, допустимое для 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 semaphore. Повторная проверка подлинности таким образом может быть определена с помощью ведения журнала отладки службы net Logon. Дополнительные сведения о том, как использовать файл Netlogon.log для отладки службы входа в сеть, щелкните следующий номер статьи, чтобы просмотреть статью в Базе знаний Майкрософт:
109626 Включение ведения журнала отладки для службы входа в сеть

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

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

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