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

Este artigo descreve alguns conceitos básicos do LSASS (Local Security Authority Subsystem Service, também conhecido como processo Lsass.exe), práticas recomendadas para a configuração do LSASS e expectativas para o uso da memória. Este artigo deve ser usado como um guia na análise do desempenho LSASS e uso de memória em controladores de domínio (DCs). 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 autoridade de segurança local (LSA) e pelo gerenciamento do Ative Directory. O LSASS lida com a autenticação do cliente e do servidor e também controla o mecanismo do Ative Directory. A LSASS é responsável pelos seguintes componentes:

• Autoridade de Segurança Local
• Serviço NetLogon
• Serviço SAM (Security Accounts Manager)
• Serviço LSA Server
• SSL (Secure Sockets Layer)
• Protocolo de autenticação Kerberos v5
• Protocolo de autenticação NTLM
• Outros pacotes de autenticação que são carregados no LSA

Os serviços de banco de dados do Ative 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 Ative Directory. Quando os dados são consultados, eles são armazenados em cache na memória. Como resultado, é normal ver LSASS usando uma quantidade de memória maior do que o tamanho do arquivo de banco de dados do Ative Directory (NTDS.dit).

Como ilustrado no diagrama, o uso da memória LSASS pode ser dividido em várias partes, incluindo o cache de buffer do banco de dados ESE, o armazenamento de versão ESE e outros. O restante deste artigo fornece informações sobre cada uma dessas partes.

Cache de buffer do banco de dados ESE

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

Repositório de Versões ESE

Há utilização variável de memória pelo armazenamento de versão 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 uma máquina de 64 bits para o armazenamento de versões ESE. Para obter mais informações sobre como o armazenamento de versão é usado, consulte 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 armazenamento da versão 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 detalhes sobre essa solução de problemas e a solução de problemas do repositório de versões, consulte outro ótimo blog de Ryan Ries: Deep Dive: Ative Directory ESE Version Store Changes in Server 2019.

Outro uso de memória

Finalmente, há código, pilhas, pilhas e várias estruturas de dados de tamanho fixo (por exemplo, o cache de esquema). A quantidade de memória que o LSASS usa pode variar, dependendo da carga no computador. À medida que o número de threads em execução aumenta, aumenta também o número de pilhas de memória. 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 utiliza o máximo de RAM possível num determinado DC. LSASS renuncia a essa RAM como outros processos pedem. A ideia é otimizar o desempenho do LSASS enquanto ainda contabiliza outros processos que podem ser executados em um computador. A lista de programas a ter em atenção inclui agentes de monitorização. Alguns clientes têm agentes separados para várias funções de servidor que podem consumir recursos de RAM consideráveis. Alguns podem emitir muitas consultas WMI, para as quais temos alguns detalhes abaixo.

Por isso e para 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 Ative Directory e, portanto, obter o desempenho ideal.

Quando notar que um DC tem problemas de desempenho, observe também os processos com utilização significativa da memória. Estes podem ter um problema que precisas 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 seu DC.

Existem recursos integrados do sistema operacional que podem consumir RAM significativa, dependendo do perfil de uso:

• Servidor de ficheiros. Os DCs também atuam como servidores de arquivos para os partilhamentos SYSVOL e Netlogon, fornecendo políticas de grupo e scripts para políticas e scripts de inicialização/logon. No entanto, vemos os clientes usarem DCs para atender a outros conteúdos de arquivos. O servidor de arquivos SMB consumiria RAM para rastrear os clientes ativos, mas, acima de tudo, o conteúdo do arquivo faria o cache de arquivos do sistema operacional crescer e competir com o cache do banco de dados ESE para RAM.

• Consultas WMI. As soluções de monitorização geralmente fazem muitas consultas WMI. Uma consulta individual pode ser barata de executar. Muitas vezes, é o volume de chamadas que incorre em alguma sobrecarga, especialmente porque 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 de DCs.

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