Consideraciones sobre el uso de memoria para la optimización del rendimiento de AD DS

En este artículo se describen algunos aspectos básicos del servicio de subsistema de autoridad de seguridad local (LSASS, también conocido como proceso Lsass.exe), procedimientos recomendados para la configuración de LSASS y expectativas de uso de memoria. Este artículo se debe usar como guía en el análisis del rendimiento y el uso de memoria de LSASS en controladores de dominio (DC). La información de este artículo puede ser útil si tiene preguntas sobre cómo ajustar y configurar servidores y controladores de dominio para optimizar este motor.

LSASS es responsable de la administración de la autenticación de dominio de la autoridad de seguridad local (LSA) y la administración de Active Directory. LSASS controla la autenticación tanto del cliente como del servidor, y también controla el motor de Active Directory. LSASS es responsable de los siguientes componentes:

• Autoridad de seguridad local
• Servicio NetLogon
• Servicio Administrador de cuentas de seguridad (SAM)
• Servicio LSA Server
• Capa de sockets seguros (SSL)
• Protocolo de autenticación Kerberos v5
• protocolo de autenticación NTLM
• Otros paquetes de autenticación que se cargan en LSA

Los servicios de base de datos de Active Directory (NTDSAI.dll) funcionan con el motor de almacenamiento extensible (ESE, ESENT.dll).

Este es un diagrama visual del uso de memoria de LSASS en un controlador de dominio:

La cantidad de memoria que usa LSASS en un controlador de dominio aumenta con el uso de Active Directory. Cuando se consultan datos, se almacenan en la memoria caché. Como resultado, es normal ver cómo LSASS usa una cantidad de memoria mayor que el tamaño del archivo de base de datos de Active Directory (NTDS.dit).

Como se muestra en el diagrama, el uso de memoria de LSASS se puede dividir en varias partes, como la caché del búfer de base de datos de ESE, el almacén de versiones de ESE y otras. En el resto de este artículo se proporciona información sobre cada una de ellas.

Caché del búfer de base de datos de ESE

El mayor uso de memoria variable dentro de LSASS es la caché del búfer de la base de datos de ESE. El tamaño de la caché puede ir de menos de 1 MB al tamaño de toda la base de datos. Dado que una caché mayor mejora el rendimiento, el motor de base de datos para Active Directory (ESENT) intenta mantenerla lo más grande posible. Aunque el tamaño de la caché varía con la presión de memoria en el equipo, el tamaño máximo de la caché del búfer de base de datos de ESE solo está limitado por la RAM física instalada en el equipo. Siempre que no haya ninguna otra presión de memoria, la caché puede crecer hasta el tamaño del archivo de base de datos NTDS.dit de Active Directory. Cuanto mayor sea la base de datos que se puede almacenar en caché, mejor será el rendimiento del controlador de dominio.

Almacén de versiones de ESE

Hay un uso variable de memoria por parte del almacén de versiones de ESE (la parte roja en el diagrama anterior). La cantidad de memoria usada depende de si tiene Windows Server 2019 o versiones anteriores de Windows.

• En las versiones de Windows Server anteriores a Windows Server 2019, LSASS puede usar de forma predeterminada hasta 400 MB de memoria (según el número de CPU) en una máquina de 64 bits para el almacén de versiones de ESE. Para más información sobre cómo se usa el almacén de versiones, consulte la siguiente entrada de blog de ASKDS de Ryan Ries: El almacén de versiones ha llamado y no les quedan cubos.

• En Windows Server 2019, esto se simplifica y, cuando se inicia por primera vez el servicio NTDS, el tamaño del almacén de versiones de ESE ahora se calcula como el 10 % de la RAM física, con un mínimo de 400 MB y un máximo de 4 GB. Para más información al respecto y la solución de problemas del almacén de versiones, consulte otro excelente blog de Ryan Ries: Análisis detallado: Cambios en el almacén de versiones de ESE de Active Directory en Server 2019.

Otro uso de memoria

Por último, hay código, pilas, montones y varias estructuras de datos de tamaño fijo (por ejemplo, la caché de esquemas). La cantidad de memoria que usa LSASS puede variar, dependiendo de la carga en el equipo. A medida que aumenta el número de subprocesos en ejecución, también lo hace el número de pilas de memoria. Por término medio, LSASS usa entre 100 MB y 300 MB de memoria para estos componentes fijos. Cuando hay una mayor cantidad de RAM instalada, LSASS puede usar más RAM y menos memoria virtual.

Limitar o minimizar el número de programas en el controlador de dominio O agregar RAM adicional cuando corresponda

Para obtener un rendimiento óptimo, LSASS ocupa tanta RAM como sea posible en un controlador de dominio determinado. LSASS renuncia a esa RAM mientras otros procesos la solicitan. La idea es optimizar el rendimiento de LSASS sin dejar de tener en cuenta otros procesos que puedan ejecutarse en un equipo. La lista de programas que se deben inspeccionar incluye agentes de supervisión. Algunos clientes tienen distintos agentes para varias funciones de servidor que pueden consumir recursos de RAM considerables. Otros pueden emitir muchas consultas WMI, para las que tenemos algunos detalles a continuación.

Debido a esto y para aumentar el rendimiento, se recomienda limitar o minimizar el número de programas en un controlador de dominio. Si no hay ninguna solicitud de memoria, LSASS usa esta memoria para almacenar en caché la base de datos de Active Directory y, por tanto, lograr un rendimiento óptimo.

Cuando note que un controlador de dominio tiene problemas de rendimiento, observe también los procesos con un uso significativo de la memoria. Pueden tener un problema que deba solucionar. Pueden incluir componentes de Microsoft. Asegúrese de mantenerse al día con las actualizaciones de mantenimiento recientes: como parte de las actualizaciones de calidad, Microsoft incluye soluciones para un uso excesivo de memoria, lo que también puede ayudar al rendimiento del controlador de dominio.

Hay recursos de sistema operativo integrados que pueden consumir bastante RAM en función del perfil de uso:

• Servidor de archivos. Los controladores de dominio también son servidores de archivos para los recursos compartidos SYSVOL y Netlogon, que dan servicio a la directiva de grupo, así como a los scripts de la directiva y los de inicio e inicio de sesión. Sin embargo, vemos que los clientes usan controladores de dominio para dar servicio a otro contenido de archivo. El servidor de archivos SMB consumiría entonces RAM para rastrear a los clientes activos, pero sobre todo, el contenido del archivo haría crecer la caché de archivos del sistema operativo, y competiría con la caché de la base de datos de ESE por la RAM.

• Consultas WMI. Las soluciones de supervisión suelen realizar muchas consultas WMI. Una consulta puede ser barata de ejecutar. A menudo es el volumen de llamadas lo que genera cierta sobrecarga, especialmente cuando las soluciones de supervisión extraen nuevos eventos de los diversos registros de eventos que administra Windows.

  El registro de eventos que genera el mayor volumen suele ser el registro de eventos de seguridad. Y también es el registro de eventos el que los administradores de seguridad quieren recopilar, especialmente de los controladores de dominio.

  El servicio WMI usa un esquema de asignación de memoria dinámica que optimiza las consultas. Por lo tanto, el servicio WMI puede asignar mucha memoria y competir de nuevo con la caché de la base de datos de ESE.