Consideraciones de uso de memoria para el ajuste del rendimiento de AD DS

En este artículo se describen algunos aspectos básicos del servicio del subsistema de autoridad de seguridad local (LSASS, también conocido como proceso de Lsass.exe), los procedimientos recomendados para la configuración de LSASS y las expectativas de uso de memoria. Este artículo debe usarse como guía en el análisis del rendimiento y uso de memoria de LSASS en controladores de dominio. 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 para el cliente como para el servidor, y también rige 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 de servidor LSA
• 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 en función del uso de Active Directory. Cuando se consultan los datos, se almacena en caché en la memoria. Como resultado, es normal ver LSASS con 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, incluida la caché del búfer de base de datos ESE, el almacén de versiones de ESE y otros. El resto de este artículo proporciona información sobre cada una de estas partes.

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 base de datos ESE. El tamaño de la caché puede oscilar entre menos de 1 MB y el 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 mantener la memoria caché 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 ESE solo está limitado por la RAM física instalada en el equipo. Siempre que no haya ninguna otra presión de memoria, la memoria caché puede crecer hasta el tamaño del archivo de base de datos NTDS.dit de Active Directory. Cuanto más sea la base de datos que se puede almacenar en caché, mejor será el rendimiento del controlador de dominio.

Nota:

Debido a la forma en que funciona el algoritmo de almacenamiento en caché de la base de datos, en un sistema de 64 bits en el que el tamaño de la base de datos es menor que la RAM disponible, la memoria caché de la base de datos puede aumentar más que el tamaño de la base de datos en un 30 al 40 %.

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, de forma predeterminada, LSASS puede usar hasta 400 MB de memoria (según el número de CPU) en un equipo 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 el servicio NTDS por primera vez, el tamaño del almacén de versiones de ESE ahora se calcula como 10% de RAM física, con un mínimo de 400 MB y un máximo de 4 GB. Para obtener información detallada sobre esta cuestión y la resolución de problemas del almacén de versiones, consulte otro excelente blog de Ryan Ries: "Deep Dive: Active Directory ESE Version Store Changes in 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 aumenta el número de pilas de memoria. En promedio, LSASS usa 100 MB a 300 MB de memoria para estos componentes fijos. Cuando se instala una mayor cantidad de RAM, LSASS puede usar más RAM y menos memoria virtual.

Limite o minimice el número de programas en el controlador de dominio O agregue ram adicional cuando corresponda.

Para obtener un rendimiento óptimo, LSASS ocupa tanta RAM como sea posible en un controlador de dominio determinado. LSASS libera la RAM a medida que otros procesos la solicitan. La idea es optimizar el rendimiento de LSASS mientras sigue teniendo en cuenta otros procesos que se pueden ejecutar en un equipo. La lista de programas que se deben vigilar incluye agentes de supervisión. Algunos clientes tienen agentes independientes 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, es recomendable limitar o minimizar el número de programas en un controlador de dominio. Si no hay solicitudes 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 observe que un controlador de dominio tiene problemas de rendimiento, vigile también los procesos con un uso significativo de memoria. Estos pueden tener un problema que debe solucionar. Pueden incluir componentes de Microsoft. Asegúrese de mantenerse al día con las actualizaciones de mantenimiento recientes: Microsoft incluye soluciones para un uso excesivo de memoria como parte de las actualizaciones de calidad, lo que también puede ayudar al rendimiento del controlador de dominio.

Hay instalaciones del sistema operativo integradas que pueden consumir RAM significativa 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 individual puede ser barata de ejecutar. A menudo es el volumen de llamadas que incurre en cierta sobrecarga, especialmente cuando las soluciones de supervisión extraen nuevos eventos de los distintos 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 una gran cantidad de memoria, y volver a competir con la memoria caché de la base de datos ESE.