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

Рекомендации по LDAP в настройке производительности ADDS

Внимание

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

Проверка запросов LDAP

Убедитесь, что запросы LDAP соответствуют рекомендациям по созданию эффективных запросов.

Существует обширная документация по MSDN о том, как правильно писать, структурировать и анализировать запросы для использования в Active Directory. Дополнительные сведения см. в статье "Создание более эффективных приложений с поддержкой Microsoft Active Directory".

Оптимизация размеров страниц LDAP

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

Если запросы имеют много результатов, может возникнуть ограничение аналогичных запросов одновременно выполняемых. Это происходит, так как сервер LDAP может истощение глобальной области памяти, известной как пул файлов cookie. Возможно, потребуется увеличить размер пула, как описано в разделе "Обработка файлов cookie сервера LDAP".

Чтобы настроить эти параметры, ознакомьтесь с разделом Windows Server 2008 и более новым контроллером домена, который возвращает только 5000 значений в ответе LDAP.

Определение того, следует ли добавлять индексы

Атрибуты индексирования полезны при поиске объектов с именем атрибута в фильтре. Индексирование может уменьшить количество объектов, которые необходимо посетить при оценке фильтра. Однако это снижает производительность операций записи, так как индекс необходимо обновить при изменении или добавлении соответствующего атрибута. Он также увеличивает размер базы данных каталогов, хотя преимущества часто перевешивают затраты на хранение. Ведение журнала можно использовать для поиска дорогостоящих и неэффективных запросов. После определения рассмотрите возможность индексирования некоторых атрибутов, которые используются в соответствующих запросах для повышения производительности поиска. Дополнительные сведения о работе поиска Active Directory см. в статье о работе поиска Active Directory.

Сценарии, которые выигрывают при добавлении индексов

  • Загрузка клиента при запросе данных создает значительное использование ЦП, а поведение запроса клиента не может быть изменено или оптимизировано.

  • Нагрузка клиента создает значительный объем операций ввода-вывода на сервере из-за неиндексированного атрибута, а поведение клиентского запроса невозможно изменить или оптимизировать.

  • Запрос занимает много времени и не завершается в приемлемом периоде времени клиенту из-за отсутствия покрытия индексов.

  • Большие объемы запросов с высокой длительностью вызывают потребление и исчерпание потоков LDAP ATQ. Отслеживайте следующие счетчики производительности:

    • Задержка NTDS\Request — это зависит от времени, сколько времени требуется для обработки запроса. Active Directory истекает время ожидания запросов через 120 секунд (по умолчанию), однако большинство должно выполняться гораздо быстрее и очень длительные запросы должны быть скрыты в общих числах. Найдите изменения в этом базовом плане, а не абсолютные пороговые значения.

      Примечание.

      Здесь также могут быть индикаторы задержек в запросах на прокси-серверы к другим доменам и проверка CRL.

    • NTDS\Оценочная задержка очереди. Это в идеале должно быть почти 0 для оптимальной производительности, так как это означает, что запросы не тратят время ожидания обслуживания.

Эти сценарии можно обнаружить с помощью одного или нескольких следующих подходов:

Другие рекомендации по индексу

  • Убедитесь, что создание индекса является правильным решением проблемы после настройки запроса было исчерпано в качестве параметра. Правильное определение размера оборудования очень важно. Индексы следует добавлять только в том случае, если правильное исправление — индексировать атрибут, а не пытаться скрыть аппаратные проблемы.

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

  • Если поведение поиска преимущественно выполняется на уровне подразделения организации, рассмотрите возможность индексирования для контейнерных поисковых запросов.

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

  • Если поведение поиска преимущественно выполняется на уровне подразделения организации, рассмотрите возможность индексирования для контейнерных поисковых запросов.

  • Индексы кортежей необходимы для поддержки строк поиска медиалов и конечных строк поиска. Индексы кортежей не требуются для начальных строк поиска.

    • Начальная строка поиска — (samAccountName=MYPC*)

    • Строка поиска medial — (samAccountName=*MYPC*)

    • Последняя строка поиска — (samAccountName=*MYPC$)

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

  • Влияние на реплика трафик минимальный, так как сборка индексов происходит локально.

Дополнительные сведения см. в следующих статьях:

Дополнительные справочники