El consumo de "Memoria total del servidor" de SQL Server se estancó durante meses con más de 64 GB disponibles

Me he encontrado con un problema extraño en el que SQL Server 2016 Standard Edition de 64 bits parecía haberse limitado a la mitad de la memoria total asignada (64 GB de 128 GB).

La salida de @@VERSIONes:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 de diciembre de 2017 11:25:00 Copyright (c) Microsoft Corporation Standard Edition (64 bits) en Windows Server 2012 R2 Datacenter 6.3 ( Build 9600:) (Hipervisor)

La salida de sys.dm_os_process_memoryes:

Cuando hago una consulta sys.dm_os_performance_counters, veo que Target Server Memory (KB)está en 131072000y Total Server Memory (KB)está en menos de la mitad de eso en 65308016. En la mayoría de los escenarios, entendería que esto es un comportamiento normal ya que SQL Server aún no ha determinado que necesita asignar más memoria para sí mismo.

Sin embargo, se ha "atascado" a ~ 64 GB durante más de 2 meses. Durante este período de tiempo, hemos realizado una cantidad significativa de operaciones de uso intensivo de memoria en algunas de las bases de datos, y hemos agregado cerca de 40 bases de datos más a la instancia. Estamos sentados en 292 bases de datos en total, cada uno con archivos de datos preasignados a 4 GB con una tasa de crecimiento automático de 256 MB y archivos de registro de 2 GB con una tasa de crecimiento automático de 128 MB. Realizo una copia de seguridad completa una vez por la noche a las 12:00 a.m., y comienzo las copias de seguridad del registro de transacciones de lunes a viernes a partir de las 6:00 a.m. a las 8:00 p.m.en un intervalo de cada 15 minutos. Estas bases de datos son relativamente bajas en su rendimiento general, pero soy escéptico de que algo esté mal dado que SQL Server no se ha acercadoTarget Server Memory naturalmente, a través de nuevas adiciones de bases de datos, ejecuciones de consultas normales, así como canalizaciones ETL con uso intensivo de memoria que se han ejecutado.

La instancia de SQL Server en sí se encuentra sobre un servidor Windows Server 2012R2 virtualizado (VMware) con 12 CPU, 144 GB de memoria (128 GB a SQL Server, 16 GB reservados para Windows) y 4 discos virtuales totales que se ubican sobre un vSAN con unidades SAS de 15K . Windows se encuentra naturalmente en un disco C de 64 GB con un archivo de página de 32 GB. Los archivos de datos se encuentran en un disco D de 2TB, los archivos de registro se encuentran encima de un disco L: de 2TB y tempdb se encuentra en un disco T: de 256GB con archivos de 8x16GB sin crecimiento automático.

He verificado que no hay otras instancias de SQL Server ejecutándose en el servidor además MSSQLSERVER.

Este servidor está completamente dedicado solo a la instancia de SQL Server, por lo que no tenemos otras aplicaciones o servicios en ejecución que puedan consumir memoria.

Utilizo RedGate SQL Monitor para el análisis, y a continuación se muestra un historial de los últimos 18 días Total Server Memory. Como puede ver, la utilización de la memoria se ha mantenido completamente estancada, aparte de un aumento de ~ 300 MB a principios de abril.

¿Cuál podría ser la causa de esto? ¿Qué puedo mirar más de cerca para determinar por qué SQL Server no quiere usar los 64 GB + de memoria adicionales asignados a él?

La salida de correr sp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Prioridad 50: Rendimiento :

• Programadores de CPU sin conexión: SQL Server no puede acceder a algunos núcleos de CPU debido a problemas de enmascaramiento o licencias de afinidad.

• Nodos de memoria sin conexión: debido a problemas de enmascaramiento o licencias de afinidad, es posible que parte de la memoria no esté disponible.

Prioridad 50: Fiabilidad :

• DAC remoto deshabilitado: el acceso remoto a la conexión de administrador dedicada (DAC) no está habilitado. El DAC puede hacer que la solución de problemas remotos sea mucho más fácil cuando SQL Server no responde.

Prioridad 100: Rendimiento :

• Muchos planes para una consulta: hay 300 planes para una sola consulta en la memoria caché del plan, lo que significa que probablemente tengamos problemas de parametrización.

• Activadores de servidor habilitados

  • El activador del servidor [RG_SQLLighthouse_DDLTrigger] está habilitado. Asegúrese de comprender lo que está haciendo ese disparador: cuanto menos trabajo haga, mejor.

  • El activador del servidor [SSMSRemoteBlock] está habilitado. Asegúrese de comprender lo que está haciendo ese disparador: cuanto menos trabajo haga, mejor.

Prioridad 150: Rendimiento :

• Consultas que fuerzan sugerencias de unión: se han registrado 1480 instancias de sugerencias de unión desde el reinicio. Esto significa que las consultas están controlando el optimizador de SQL Server, y si no saben lo que están haciendo, esto puede causar más daño que bien. Esto también puede explicar por qué los esfuerzos de ajuste de DBA no están funcionando.

• Consultas para forzar sugerencias de órdenes: se han registrado 2153 instancias de sugerencias de órdenes desde el reinicio. Esto significa que las consultas están controlando el optimizador de SQL Server, y si no saben lo que están haciendo, esto puede causar más daño que bien. Esto también puede explicar por qué los esfuerzos de ajuste de DBA no están funcionando.

Prioridad 170: Configuración de archivo :

• Base de datos del sistema en la unidad C

  • master: la base de datos master tiene un archivo en la unidad C. Poner las bases de datos del sistema en la unidad C corre el riesgo de colapsar el servidor cuando se queda sin espacio.

  • modelo: la base de datos modelo tiene un archivo en la unidad C. Poner las bases de datos del sistema en la unidad C corre el riesgo de colapsar el servidor cuando se queda sin espacio.

  • msdb: la base de datos msdb tiene un archivo en la unidad C. Poner las bases de datos del sistema en la unidad C corre el riesgo de colapsar el servidor cuando se queda sin espacio.

Prioridad 200: Informativo :

• Trabajos del agente que se inician simultáneamente: varios trabajos del Agente SQL Server están configurados para iniciarse simultáneamente. Para ver listados detallados de horarios, consulte la consulta en la URL.

• Tablas en la base de datos maestra maestra: los usuarios finales crearon la tabla CommandLog en la base de datos maestra el 30 de julio de 2017 a las 5:22 p.m. Las tablas en la base de datos maestra no pueden restaurarse en caso de un desastre.

• TraceFlag On

  • La marca de seguimiento 1118 está habilitada globalmente.

  • La marca de seguimiento 1222 está habilitada globalmente.

  • La marca de seguimiento 2371 está habilitada globalmente.

Prioridad 200: Configuración del servidor no predeterminada :

• XP del agente: esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 1.

• valor predeterminado de suma de comprobación de respaldo: esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 1.

• valor predeterminado de compresión de respaldo: esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 1.

• umbral de costo para paralelismo: esta opción sp_configure ha cambiado. Su valor predeterminado es 5 y se ha establecido en 48.

• grado máximo de paralelismo: esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 12.

• memoria máxima del servidor (MB): esta opción sp_configure ha cambiado. Su valor predeterminado es 2147483647 y se ha establecido en 128000.

• optimizar para cargas de trabajo ad hoc: esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 1.

• Mostrar opciones avanzadas: esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 1.

• xp_cmdshell: esta opción de sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 1.

Prioridad 200: Fiabilidad :

• Procedimientos almacenados extendidos en Master

• maestro: el procedimiento almacenado extendido [sqbdata] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • master: el procedimiento almacenado extendido [sqbdir] está en la base de datos master. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • master: el procedimiento almacenado extendido [sqbmemory] está en la base de datos master. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • maestro: el procedimiento almacenado extendido [sqbstatus] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • maestro: el procedimiento almacenado extendido [sqbtest] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • maestro: el procedimiento almacenado extendido [sqbtestcancel] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • maestro: el procedimiento almacenado extendido [sqbteststatus] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • maestro: el procedimiento almacenado extendido [sqbutility] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

  • maestro: el procedimiento almacenado extendido [sqlbackup] está en la base de datos maestra. CLR puede estar en uso, y la base de datos maestra ahora debe ser parte de su planificación de copia de seguridad / recuperación.

Prioridad 210: Configuración de base de datos no predeterminada :

• Lectura de aislamiento de instantánea comprometida habilitada: esta configuración de base de datos no es la predeterminada.

  • RedGate

  • RedGateMonitor

• Aislamiento de instantánea habilitado: esta configuración de base de datos no es la predeterminada.

  • RedGate

  • RedGateMonitor

Prioridad 240: Estadísticas de espera :

• 1 - SOS_SCHEDULER_YIELD - 1770.8 horas de espera, 115.9 minutos de tiempo de espera promedio por hora, 100.0% de espera de señal, 1419212079 tareas de espera, 4.5 ms de tiempo de espera promedio.

Prioridad 250: Informativo :

• SQL Server se ejecuta bajo una cuenta de servicio NT: estoy ejecutando como servicio NT \ MSSQLSERVER. Desearía tener una cuenta de servicio de Active Directory.

Prioridad 250: Información del servidor :

• Contenido de rastreo predeterminado: el rastreo predeterminado contiene 36 horas de datos entre el 14 de abril de 2018 a las 11:21 p.m. y el 16 de abril de 2018 a las 11:13 a.m. Los archivos de rastreo predeterminados se encuentran en: C: \ Archivos de programa \ Microsoft SQL Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log

• Unidad C Space - 196816.00MB gratis en unidad C

• Unidad D Space - 894823.00MB gratis en unidad E

• Drive L Space - 1361367.00MB gratis en la unidad F

• Drive T Space - 114441.00MB gratis en la unidad G

• Hardware - Procesadores lógicos: 12. Memoria física: 144 GB.

• Hardware - Configuración NUMA

  • Nodo: 0 Estado: en línea Programadores en línea: 4 Programadores en línea: 2 Grupo de procesadores: 0 Nodo de memoria: 0 Memoria VAS reservada GB: 186

  • Nodo: 1 Estado: SIN CONEXIÓN Programadores en línea: 0 Programadores sin conexión: 6 Grupo de procesadores: 0 Nodo de memoria: 0 Memoria VAS reservada GB: 186

• Inicialización instantánea de archivos habilitada: la cuenta de servicio tiene el permiso Realizar tareas de mantenimiento de volumen.

• Plan de energía: su servidor tiene CPU de 2.60 GHz y está en modo de energía equilibrado. Uh ... desea que sus CPU funcionen a toda velocidad, ¿verdad?

• Último reinicio del servidor - 9 de marzo de 2018 7:27 a.m.

• Nombre del servidor - [redactado]

• Servicios

  • Servicio: SQL Server (MSSQLSERVER) se ejecuta bajo la cuenta de servicio NT Service \ MSSQLSERVER. Última hora de inicio: 9 de marzo de 2018 7:27 a.m. Tipo de inicio: Automático, actualmente en ejecución.

  • Servicio: el Agente SQL Server (MSSQLSERVER) se ejecuta bajo la cuenta de servicio LocalSystem. Última hora de inicio: no se muestra. Tipo de inicio: Automático, actualmente en ejecución.

• Último reinicio de SQL Server - 9 de marzo de 2018 6:27 a.m.

• Servicio SQL Server - Versión: 13.0.4466.4. Nivel de parche: SP1. Actualización acumulativa: CU7. Edición: Edición estándar (64 bits). Grupos de disponibilidad habilitados: 0. Estado del administrador de grupos de disponibilidad: 2

• Servidor virtual - Tipo: (HYPERVISOR)

• Versión de Windows: está ejecutando una versión bastante moderna de Windows: Server 2012R2 era, versión 6.3

Prioridad 254: Rundate :

• Registro del capitán: fecha estelar algo y algo ...

Apuesto a que ha configurado las CPU virtuales de manera que algunos de los nodos de CPU y / o nodos de memoria estén desconectados.

Descargue sp_Blitz (descargo de responsabilidad: soy uno de los autores de ese script de código abierto gratuito) y ejecútelo:

sp_Blitz @CheckServerInfo = 1;

Busque advertencias sobre CPU y / o nodos de memoria que están fuera de línea. SQL Server Standard Edition solo ve los primeros 4 zócalos de CPU, y es posible que haya configurado la VM como algo así como 6 CPU de doble núcleo. Terminará teniendo un problema similar a cómo los límites de 20 núcleos de Enterprise Edition limitan la cantidad de memoria que puede ver .

Si desea compartir el resultado de sp_Blitz aquí, puede ejecutarlo de esta manera para enviarlo a Markdown, que luego puede copiar / pegar en su pregunta:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Actualización 2018/04/16 - confirmado. Adjuntó la salida de sp_Blitz (¡gracias por eso!) Y de hecho muestra que tiene CPU y nodos de memoria fuera de línea. Quien haya creado la VM la configuró como 12 CPU de un solo núcleo, por lo que SQL Server Standard Edition solo está viendo los primeros 4 sockets (núcleos) y la memoria conectada a ellos.

Para solucionarlo, apague la VM, configúrela como una VM de 2 sockets y 6 núcleos, y luego SQL Server Standard Edition verá todos los núcleos y la memoria. Esto también reducirá sus esperas SOS_SCHEDULER_YIELD también: en este momento, su SQL Server está martillando los primeros 4 núcleos, pero eso es todo. Después de esta solución, podrá funcionar en los 12 núcleos.

Como una adición al plan de acción de Brent Ozar , quería compartir los resultados. Como señaló Brent, dentro de VMware habíamos configurado la máquina virtual de manera incorrecta con 12 CPU de un solo núcleo. Esto dio como resultado que SQL Server no pudiera acceder a los 8 núcleos restantes y, como resultado, condujo al problema de memoria descrito en mi pregunta original. Anoche colocamos nuestros servicios en modo de mantenimiento para reconfigurar la VM de manera adecuada. No solo estamos viendo que la memoria se arrastra de manera normal, sino que, como Brent también insinuó, el número de esperas disminuyó exponencialmente y nuestro rendimiento general de SQL Server se ha disparado. Las configuraciones de vNUMA ahora son pequeños componentes felices que están dividiendo nuestras cargas de trabajo.

Para aquellos que podrían estar utilizando VMware vSphere 6.5, los breves pasos para completar el elemento de acción descrito por Brent son los siguientes.

1. Inicie sesión en vSphere Web Client para su clúster VMware y busque la máquina virtual que aloja SQL Server. Su VM debe estar fuera de línea para ajustar las configuraciones de CPU y memoria.

2. Dentro del panel principal, vaya a Configure > VM hardware, haga clic en el Editbotón en la esquina superior derecha. Abrirás un menú contextual que tiene Edit Settings. Como referencia, la imagen a continuación es la configuración incorrecta . Tenga en cuenta que me he Cores per Socketpuesto a 1. Dadas las limitaciones de SQL Server Standard Edition, esta es una mala configuración.

   

3. La solución es tan simple como ajustar el Cores per Socketvalor. En nuestro caso, lo configuramos para 6que lo tengamos 2 Sockets. Esto permite que SQL Server utilice los 12 procesadores.

   

Una nota importante: no establezca el valor donde sea que el Number of Coreso el Socketssea ​​un número impar. NUMA ama el equilibrio y, por regla general, debe ser divisible por 2. Por ejemplo, una configuración de 4 núcleos a 3 zócalos estaría desequilibrada. De hecho, si tuviera que ejecutar sp_Blitzeste tipo de configuración, arrojaría una advertencia al respecto.

La Sección 3.3 en Arquitectura de Microsoft SQL Server en VMware vSphere (advertencia en PDF) describe esto en detalle. Las prácticas descritas en el documento técnico son aplicables a la mayoría de las virtualizaciones locales de SQL Server.

Aquí hay algunos recursos más que he compilado a través de mi investigación después de la publicación de Brent:

• Virtualización de grandes bases de datos: planificación de la capacidad de CPU de VMware

• Virtual Machine vCPU y vNUMA Rightsizing - Reglas prácticas

• Desacoplamiento de núcleos por socket de la topología virtual NUMA en vSphere 6.5

Terminaré con una captura de RedGate SQL Monitor en las últimas 24 horas. El punto principal de la nota es la utilización de la CPU y el número de esperas: durante nuestras horas pico de ayer, estábamos experimentando un uso intensivo de la CPU y contenciones de espera. Después de esta simple solución, hemos mejorado nuestro rendimiento diez veces. Incluso nuestra E / S de disco se ha reducido significativamente. Esta es una configuración aparentemente fácil de pasar por alto que puede mejorar el rendimiento virtual en un orden de magnitud. Por lo menos, se pasó por alto por nuestros ingenieros y un completo d'oh momento.

Además, según MSDN , el estándar de SQL Server está limitado a 64 GB de RAM. 'Resolvimos' esto dividiendo la base de datos en varias instancias, pero su situación podría no permitirlo.

Hmm 2016 parece tener 128 GB como límite, pero la división de instancias podría ser una opción aún.