Considerações de uso de memória para ajuste de desempenho do AD DS

Este artigo descreve alguns conceitos básicos do LSASS (Serviço de Subsistema da Autoridade de Segurança Local, também conhecido como processo de Lsass.exe), práticas recomendadas para a configuração do LSASS e expectativas de uso de memória. Este artigo deve ser usado como um guia na análise do desempenho do LSASS e do uso de memória em DCs (controladores de domínio). As informações neste artigo podem ser úteis se você tiver dúvidas sobre como ajustar e configurar servidores e DCs para otimizar esse mecanismo.

O LSASS é responsável pelo gerenciamento da autenticação de domínio da LSA (autoridade de segurança local) e do gerenciamento do Active Directory. O LSASS manipula a autenticação para o cliente e o servidor e também controla o mecanismo do Active Directory. O LSASS é responsável pelos seguintes componentes:

• Autoridade de Segurança Local
• Serviço NetLogon
• Serviço SAM (Gerenciador de Contas de Segurança)
• Serviço de servidor LSA
• Camada de soquetes seguros (SSL)
• Protocolo de autenticação Kerberos v5
• Protocolo de autenticação NTLM
• Outros pacotes de autenticação que são carregados em LSA

Os serviços de banco de dados do Active Directory (NTDSAI.dll) funcionam com o Mecanismo de Armazenamento Extensível (ESE, ESENT.dll).

Aqui está um diagrama visual do uso de memória LSASS em um DC:

A quantidade de memória que o LSASS usa em um DC aumenta de acordo com o uso do Active Directory. Quando os dados são consultados, eles são armazenados em cache na memória. Como resultado, é normal ver o LSASS usando uma quantidade de memória maior que o tamanho do arquivo de banco de dados do Active Directory (NTDS.dit).

Conforme ilustrado no diagrama, o uso da memória LSASS pode ser dividido em várias partes, incluindo o cache de buffer de banco de dados ESE, o repositório de versões do ESE e outras. O restante deste artigo fornece insights sobre cada uma dessas partes.

Cache de buffer de banco de dados ESE

O maior uso de memória variável no LSASS é o cache de buffer do banco de dados ESE. O tamanho do cache pode variar de menos de 1 MB até o tamanho de todo o banco de dados. Como um cache maior melhora o desempenho, o mecanismo de banco de dados do ESENT (Active Directory) tenta manter o cache o maior possível. Embora o tamanho do cache varie com a pressão de memória no computador, o tamanho máximo do cache de buffer do banco de dados ESE é limitado apenas pela RAM física instalada no computador. Desde que não haja outra pressão de memória, o cache poderá aumentar para o tamanho do arquivo de banco de dados NTDS.dit do Active Directory. Quanto mais do banco de dados puder ser armazenado em cache, melhor será o desempenho do DC.

Repositório de versões do ESE

Há o uso de memória variável pelo repositório de versão do ESE (a parte vermelha no diagrama acima). A quantidade de memória usada depende se você tem o Windows Server 2019 ou versões mais antigas do Windows.

• Nas versões do Windows Server anteriores ao Windows Server 2019, por padrão, o LSASS pode usar até cerca de 400 MB de memória (dependendo do número de CPUs) em um computador de 64 bits para o repositório de versões do ESE. Para mais informações sobre como o repositório de versão é usado, confira a seguinte postagem no blog ASKDS de Ryan Ries: The Version Store Called and They're All Out of Buckets.

• No Windows Server 2019, isso é simplificado e, quando o serviço NTDS é iniciado pela primeira vez, o tamanho do repositório de versão do ESE agora é calculado como 10% de RAM física, com um mínimo de 400 MB e um máximo de 4 GB. Para obter ótimos detalhes sobre essa e a solução de problemas do repositório de versões, consulte outro ótimo blog de Ryan Ries: Deep Dive: Active Directory ESE Version Store Changes in Server 2019.

Outro uso de memória

Por fim, há código, pilhas, heaps e várias estruturas de dados de tamanho fixo (por exemplo, o cache de esquema). A quantidade de memória usada pelo LSASS pode variar, dependendo da carga no computador. À medida que o número de threads em execução aumenta, o número de pilhas de memória também aumenta. Em média, o LSASS usa de 100 MB a 300 MB de memória para esses componentes fixos. Quando uma quantidade maior de RAM é instalada, o LSASS pode usar mais RAM e menos memória virtual.

Limitar ou minimizar o número de programas no controlador de domínio ou adicionar RAM adicional, quando apropriado

Para um desempenho ideal, o LSASS usa o máximo de RAM possível em um determinado DC. O LSASS abre mão dessa RAM conforme outros processos solicitam. A ideia é otimizar o desempenho do LSASS enquanto ainda contabiliza outros processos que podem ser executados em um computador. A lista de programas a serem observados inclui agentes de monitoramento. Alguns clientes têm agentes separados para várias funções de servidor que podem consumir recursos consideráveis de RAM. Algumas podem emitir muitas consultas WMI, para as quais temos alguns detalhes abaixo.

Devido a isso e aumentar o desempenho, é uma boa prática limitar ou minimizar o número de programas em um DC. Se não houver solicitações de memória, o LSASS usará essa memória para armazenar em cache o banco de dados do Active Directory e, portanto, obter um desempenho ideal.

Quando você observar que um DC tem problemas de desempenho, observe também processos com utilização significativa de memória. Eles podem ter um problema que você precisa solucionar. Eles podem incluir componentes da Microsoft. Certifique-se de acompanhar as atualizações de manutenção recentes– a Microsoft inclui soluções para utilização excessiva de memória como parte das atualizações de qualidade, o que também pode ajudar o desempenho do DC.

Há instalações internas do sistema operacional que podem consumir RAM significativa dependendo do perfil de uso:

• Servidor de arquivos. Os DCs também são servidores de arquivos para compartilhamentos SYSVOL e Netlogon, política de grupo de manutenção e scripts para scripts de política e inicialização/logon. No entanto, vemos os clientes usarem DCs para atender a outro conteúdo de arquivo. O servidor de arquivos SMB consumiria RAM para acompanhar os clientes ativos, mas, acima de tudo, o conteúdo do arquivo faria com que o cache de arquivos do sistema operacional aumentasse e competisse com o cache de banco de dados ESE para RAM.

• Consultas WMI. As soluções de monitoramento geralmente fazem muitas consultas WMI. Uma consulta individual pode ser barata de executar. Geralmente, é o volume de chamadas que incorre em alguma sobrecarga, especialmente à medida que as soluções de monitoramento extraem novos eventos dos vários logs de eventos que o Windows gerencia.

  O log de eventos que produz mais volume normalmente é o log de Eventos de Segurança. E esse também é o log de eventos que os administradores de segurança desejam coletar, especialmente dos DCs.

  O serviço WMI usa um esquema de alocação de memória dinâmica que otimiza consultas. Portanto, o serviço WMI pode alocar muita memória, competindo novamente com o cache do banco de dados ESE.