Рекомендации по использованию памяти для настройки производительности AD DS

В этой статье описаны некоторые основы службы подсистемы локального центра безопасности (LSASS, также известный как процесс Lsass.exe), рекомендации по настройке LSASS и ожидания использования памяти. Эта статья должна использоваться в качестве руководства по анализу производительности и памяти LSASS на контроллерах домена (DCs). Сведения в этой статье могут быть полезны, если у вас есть вопросы о настройке и настройке серверов и контроллеров домена для оптимизации этого модуля.

LSASS отвечает за управление проверкой подлинности домена локального центра безопасности (LSA) и управлением Active Directory. LSASS обрабатывает проверку подлинности как для клиента, так и сервера, а также управляет подсистемой Active Directory. LSASS отвечает за следующие компоненты:

• Локальная система безопасности
• Служба NetLogon
• Служба диспетчера учетных записей безопасности (SAM)
• Служба сервера LSA
• SSL
• Протокол проверки подлинности Kerberos версии 5
• Протокол проверки подлинности NTLM
• Другие пакеты проверки подлинности, загружаемые в LSA

Службы баз данных Active Directory (NTDSAI.dll) работают с подсистемой расширяемой служба хранилища (ESE, ESENT.dll).

Ниже приведена визуальная схема использования памяти LSASS на контроллере домена:

Объем памяти, используемой LSASS на контроллере домена, увеличивается в соответствии с использованием Active Directory. При запросе данных кэшируется в памяти. В результате это нормально видеть LSASS с использованием объема памяти, превышающего размер файла базы данных Active Directory (NTDS.dit).

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

Кэш буфера базы данных ESE

Наибольшее использование памяти переменной в LSASS — это кэш буфера базы данных ESE. Размер кэша может варьироваться от менее 1 МБ до размера всей базы данных. Так как большой кэш повышает производительность, ядро СУБД для Active Directory (ESENT) пытается сохранить кэш максимально большим. Хотя размер кэша зависит от нехватки памяти на компьютере, максимальный размер кэша буфера базы данных ESE ограничен физической оперативной памятью, установленной на компьютере. Пока нет другого давления на память, кэш может увеличиться до размера файла базы данных NTDS.dit Active Directory. Чем больше базы данных, которую можно кэшировать, тем лучше производительность контроллера домена.

Хранилище версий ESE

В хранилище версий ESE используется переменная память (красная часть на схеме выше). Объем используемой памяти зависит от того, есть ли у вас Windows Server 2019 или более ранние версии Windows.

• В версиях Windows Server, предшествующих Windows Server 2019, по умолчанию LSASS может использовать до 400 МБ памяти (в зависимости от количества ЦП) на 64-разрядном компьютере для хранилища версий ESE. Дополнительные сведения о том, как используется хранилище версий, см. в следующей записи блога ASKDS ryan Ries: "Хранилище версий" и "Все из контейнеров".

• В Windows Server 2019 это упрощается, и при первом запуске службы NTDS размер хранилища версий ESE теперь вычисляется как 10 % физической ОЗУ, но не менее 400 МБ и максимум 4 ГБ. Дополнительные сведения об устранении неполадок в этом и хранилище версий см. в другом отличном блоге ryan Ries: Глубокое изучение: изменения хранилища версий Active Directory ESE в Server 2019.

Другое использование памяти

Наконец, есть код, стеки, кучи и различные структуры данных фиксированного размера (например, кэш схем). Объем памяти, используемой LSASS, может отличаться в зависимости от нагрузки на компьютере. По мере увеличения числа выполняемых потоков это количество стеков памяти. В среднем LSASS использует 100 МБ до 300 МБ памяти для этих фиксированных компонентов. При установке большего объема ОЗУ LSASS может использовать больше ОЗУ и меньше виртуальной памяти.

Ограничить или свести к минимуму количество программ на контроллере домена ИЛИ добавьте дополнительные ОЗУ, если это необходимо.

Для оптимальной производительности LSASS принимает как можно больше ОЗУ на заданном контроллере домена. LSASS отклинивается, что ОЗУ, как другие процессы запрашивают его. Идея заключается в оптимизации производительности LSASS, а также учет других процессов, которые могут выполняться на компьютере. Список программ, которые следует отслеживать, включают агенты мониторинга. Некоторые клиенты имеют отдельные агенты для различных функций сервера, которые могут использовать значительные ресурсы ОЗУ. Некоторые могут выдавать много запросов WMI, для которых у нас есть несколько сведений ниже.

Из-за этого и повышения производительности рекомендуется ограничить или свести к минимуму количество программ на контроллере домена. Если нет запросов на память, LSASS использует эту память для кэширования базы данных Active Directory и, следовательно, обеспечивает оптимальную производительность.

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

Существуют встроенные средства ОС, которые могут использовать значительный объем ОЗУ в зависимости от профиля использования:

• Файловый сервер. DCs также являются файловыми серверами для общих папок SYSVOL и Netlogon, обслуживания групповой политики и скриптов для политик и скриптов запуска и входа в систему. Однако мы видим, что клиенты используют DCs для обслуживания другого содержимого файла. Затем файловый сервер S МБ будет использовать ОЗУ для отслеживания активных клиентов, но, прежде всего, содержимое файла приведет к росту кэша файлов ОС и конкурировать с кэшем базы данных ESE для ОЗУ.

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

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

  Служба WMI использует схему динамического выделения памяти, которая оптимизирует запросы. Таким образом, служба WMI может выделить много памяти, снова конкурируя с кэшем базы данных ESE.