Principales problemas de rendimiento en nuestro SQL Server de producción, ¿cómo solucionaría esto?

Esta pregunta es básicamente una pregunta de seguimiento a esta pregunta:
extraño problema de rendimiento con SQL Server 2016

Ahora fuimos productivos con este sistema. Aunque se agregó otra base de datos de aplicaciones a este SQL Server desde mi última publicación.

Estas son las estadísticas del sistema:

• 128 GB de RAM (110 GB de memoria máxima para SQL Server)
• 4 núcleos a 2.6 GHz
• Conexión de red de 10 GBit
• Todo el almacenamiento está basado en SSD
• Los archivos de programa, archivos de registro, archivos de base de datos y tempdb están en particiones separadas del servidor
• Windows Server 2012 R2
• Versión de VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools versión 10.0.9, compilación 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 de octubre de 2016 18:17:30 Copyright (c) Microsoft Corporation Standard Edition (64 bits) en Windows Server 2012 R2 Standard 6.3 (Build 9600:) (Hipervisor)

Nuestro sistema ahora tiene problemas importantes de rendimiento. Muy alto uso de CPU y conteos de hilos:

Estadísticas de espera del monitor de actividad (sé que no es muy confiable)

Resultados de sp_blitzfirst:

Resultados de sp_configure:

Configuración avanzada del servidor (desafortunadamente solo en alemán)

La configuración de MAXDOP fue modificada por mí.

Soy consciente de que esto no es un problema con el servidor SQL en sí . Es probablemente un problema con la virtualización (vmware), la red (ya lo probé) o la aplicación en sí. Solo quiero clavarlo aún más.

¿Alto ASYNC_NETWORK_IO resultaría en un alto conteo de hilos para el proceso sqlserver? Me imagino que atrae a muchos trabajadores porque los hilos no pueden cerrarse. ¿Está bien?

Le proporcionaré cualquier información adicional que necesite. ¡Gracias de antemano por su apoyo!

EDITAR:

Consecuencia de sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Prioridad 1: Copia de seguridad :

• Copia de seguridad en la misma unidad donde residen las bases de datos: 5 copias de seguridad realizadas en la unidad E: \ en las últimas dos semanas, donde también viven los archivos de la base de datos. Esto representa un riesgo grave si esa matriz falla.

Prioridad 1: Fiabilidad :

• Última buena DBCC CHECKDB más de 2 semanas de edad

  • babtec_prod - Último CHECKDB exitoso: 2017-08-20 00: 01: 01.513

  • D3PR - Último CHECKDB exitoso: nunca.

  • DEMO77 - Último CHECKDB exitoso: 2016-02-23 20: 31: 38.590

  • FINP - Último CHECKDB exitoso: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - Último CHECKDB exitoso: 2017-05-18 22: 10: 48.120

  • master - Último CHECKDB exitoso: nunca.

  • modelo

  • msdb

  • PROD77 - Último CHECKDB exitoso: 2016-02-23 21: 33: 24.343

Prioridad 10: Rendimiento :

• Almacén de consultas deshabilitado: la nueva función Almacén de consultas de SQL Server 2016 no se ha habilitado en esta base de datos.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Prioridad 50: Eventos DBCC :

• DBCC DROPCLEANBUFFERS: el usuario schorsch ha ejecutado DBCC DROPCLEANBUFFERS 1 veces entre el 21 de septiembre de 2017 a las 11:57 a.m. y el 21 de septiembre de 2017 a las 11:57 a.m. Si se trata de una caja de producción, sepa que está borrando todos los datos de la memoria cuando esto sucede. ¿Qué tipo de monstruo haría eso?

• DBCC SHRINK% - El usuario schorsch ha ejecutado archivos reducidos 6 veces entre el 21 de septiembre de 2017 11:51 PM y el 4 de octubre de 2017 9:02 AM. Entonces, ¿están tratando de arreglar la corrupción o causar corrupción?

• Eventos generales: 287 eventos de DBCC se llevaron a cabo entre el 19 de septiembre de 2017 1:40 p.m. y el 4 de octubre de 2017 3:20 p.m. Esto no incluye CHECKDB y otros eventos DBCC generalmente benignos.

Prioridad 50: Rendimiento :

• Crecimientos de archivos lentos PROD77 - 2 crecimientos tomaron más de 15 segundos cada uno. Considere configurar el crecimiento automático del archivo en un incremento menor.

Prioridad 50: Fiabilidad :

• Verificación de página no óptima babtec_prod: la base de datos [babtec_prod] tiene TORN_PAGE_DETECTION para la verificación de la página. SQL Server puede tener más dificultades para reconocer y recuperarse de la corrupción del almacenamiento. Considere usar CHECKSUM en su lugar.

Prioridad 100: Rendimiento :

• Muchos planes para una consulta: 3576 planes están presentes para una sola consulta en la caché del plan, lo que significa que probablemente tengamos problemas de parametrización.

Prioridad 110: Rendimiento :

• Tablas activas sin índices agrupados

  • babtec_prod: la base de datos [babtec_prod] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • D3PR: la base de datos [D3PR] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • DEMO77: la base de datos [DEMO77] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • FINP: la base de datos [FINP] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • GridVis_EnMs: la base de datos [GridVis_EnMs] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

  • PROD77: la base de datos [PROD77] tiene montones, tablas sin un índice agrupado, que se consultan activamente.

Prioridad 150: Rendimiento :

• Claves extranjeras no confiables

  • babtec_prod - La base de datos [babtec_prod] tiene claves foráneas que probablemente fueron deshabilitadas, los datos fueron cambiados y luego la clave fue habilitada nuevamente. Simplemente habilitar la tecla no es suficiente para que el optimizador use esta tecla; tenemos que alterar la tabla usando el parámetro WITH CHECK CHECK CONSTRAINT.

  • D3PR: la base de datos [D3PR] tiene claves foráneas que probablemente se deshabilitaron, se modificaron los datos y luego se volvió a habilitar la clave. Simplemente habilitar la tecla no es suficiente para que el optimizador use esta tecla; tenemos que alterar la tabla usando el parámetro WITH CHECK CHECK CONSTRAINT.

• Tablas inactivas sin índices agrupados

  • D3PR: la base de datos [D3PR] tiene montones, tablas sin un índice agrupado, que no se han consultado desde el último reinicio. Estas pueden ser tablas de respaldo dejadas sin cuidado.

  • GridVis_EnMs: la base de datos [GridVis_EnMs] tiene montones, tablas sin un índice agrupado, que no se han consultado desde el último reinicio. Estas pueden ser tablas de respaldo dejadas sin cuidado.

• Desencadenantes en tablas babtec_prod: la base de datos [babtec_prod] tiene 26 desencadenantes.

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 170: Fiabilidad :

• Tamaño máximo de archivo establecido

  • D3PR: el archivo de base de datos [D3PR] d3_data_01 tiene un tamaño de archivo máximo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_data_idx_01 tiene un tamaño máximo de archivo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_firm_01 tiene un tamaño de archivo máximo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_firm_idx_01 tiene un tamaño de archivo máximo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_log_01 tiene un tamaño de archivo máximo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_phys_01 tiene un tamaño de archivo máximo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_phys_idx_01 tiene un tamaño máximo de archivo establecido en 61440 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_sys_01 tiene un tamaño de archivo máximo establecido en 20480 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_usr_01 tiene un tamaño máximo de archivo establecido en 20480 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_wort_01 tiene un tamaño de archivo máximo establecido en 20480 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

  • D3PR: el archivo de base de datos [D3PR] d3_wort_idx_01 tiene un tamaño de archivo máximo establecido en 20480 MB. Si se queda sin espacio, la base de datos dejará de funcionar aunque haya espacio disponible en la unidad.

Prioridad 200: Informativo :

• Valor predeterminado de compresión de copia de seguridad desactivado: recientemente se han realizado copias de seguridad completas sin comprimir y la compresión de copia de seguridad no está activada a nivel del servidor. La compresión de respaldo se incluye con SQL Server 2008R2 y posteriores, incluso en la Edición estándar. Recomendamos activar la compresión de copia de seguridad de forma predeterminada para que las copias de seguridad ad-hoc se compriman.

• La clasificación es Latin1_General_CS_AS FINP: las diferencias de clasificación entre las bases de datos de usuario y tempdb pueden causar conflictos, especialmente al comparar valores de cadena

• La clasificación es SQL_Latin1_General_CP1_CI_AS: las diferencias de clasificación entre las bases de datos de usuario y tempdb pueden causar conflictos, especialmente al comparar valores de cadena

  • DEMO77

  • PROD77

• Servidor vinculado configurado: BWIN2 \ INFOR está configurado como un servidor vinculado. Verifique su configuración de seguridad ya que se conecta con sa, porque cualquier usuario que lo solicite obtendrá permisos de nivel de administrador.

Prioridad 200: Monitoreo :

• Trabajos de agente sin correos electrónicos fallidos

  • El trabajo syspolicy_purge_history no se ha configurado para notificar a un operador si falla.

  • El trabajo upd_durchpreis_monatl no se ha configurado para notificar a un operador si falla.

  • El trabajo upd_fertmengen_woche no se ha configurado para notificar a un operador si falla.

  • El trabajo upd_liegezeit_monatl no se ha configurado para notificar a un operador si falla.

  • El trabajo upd_vertreter_diff no se ha configurado para notificar a un operador si falla.

  • El trabajo UPDATE_CONNECT_IK no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.Cleanup no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.DBCC Check DB no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.Index neu erstellen no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.Statistiken aktualisieren no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.Transactionlog Backup no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.Vollbackup SystemDB no se ha configurado para notificar a un operador si falla.

  • El trabajo Wartung.Vollbackup UserDB no se ha configurado para notificar a un operador si falla.

• Sin alertas de corrupción: las alertas del Agente SQL Server no existen para los errores 823, 824 y 825. Estos tres errores pueden proporcionarle una notificación sobre una falla temprana del hardware. Habilitarlos puede evitar mucho desamor.

• Sin alertas para Sev 19-25: las alertas del Agente SQL Server no existen para los niveles de gravedad 19 a 25. Estos son algunos errores muy graves de SQL Server. Saber que esto sucede puede permitirle recuperarse de los errores más rápido.

• No todas las alertas configuradas: no todas las alertas del Agente SQL Server se han configurado. Esta es una manera fácil y gratuita de recibir notificaciones de corrupción, fallas en el trabajo o interrupciones importantes incluso antes de que los sistemas de monitoreo lo detecten.

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.

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

• idioma predeterminado de texto completo: esta opción sp_configure ha cambiado. Su valor predeterminado es 1033 y se ha establecido en 1031.

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

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

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

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

• min server memory (MB): esta opción sp_configure ha cambiado. Su valor predeterminado es 0 y se ha establecido en 10000.

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

Prioridad 200: Rendimiento :

• umbral de costo para paralelismo: se establece en 5, su valor predeterminado. Cambiar esta configuración de sp_configure puede reducir las esperas de CXPACKET.

• Se han producido copias de seguridad de instantáneas: se han producido 9 copias de seguridad con aspecto de instantánea en las últimas dos semanas, lo que indica que IO puede estar congelando.

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

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

  • D3PR

  • FINP

• Activadores recursivos habilitados: esta configuración de base de datos no es la predeterminada.

  • DEMO77

  • PROD77

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

Prioridad 240: Estadísticas de espera :

• 1 - ASYNC_NETWORK_IO: 225.9 horas de espera, 143.5 minutos de tiempo de espera promedio por hora, 0.2% de espera de señal, 2146022 tareas de espera, 378.9 ms de tiempo de espera promedio.

• 2 - CXPACKET: 43.1 horas de espera, 27.4 minutos de tiempo de espera promedio por hora, 1.5% de espera de señal, 32608391 tareas de espera, 4.8 ms de tiempo de espera promedio.

Prioridad 250: Informativo :

• SQL Server se ejecuta bajo una cuenta de servicio NT

  • Estoy corriendo como NT Service \ MSSQL $ INFOR. Desearía tener una cuenta de servicio de Active Directory en su lugar.

  • Me estoy ejecutando como NT Service \ SQLAgent $ INFOR. Desearía tener una cuenta de servicio de Active Directory en su lugar.

Prioridad 250: Información del servidor :

• Contenido de rastreo predeterminado: el rastreo predeterminado contiene 760 horas de datos entre el 3 de septiembre de 2017 8:34 PM y el 5 de octubre de 2017 12:50 PM. Los archivos de rastreo predeterminados se encuentran en: C: \ Archivos de programa \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Unidad C Space: 21308.00MB gratis en unidad C

• Unidad D Space - 280008.00MB gratis en unidad D
• Drive E Space - 281618.00MB gratis en la unidad E

• Unidad F Space: 60193.00MB gratis en unidad F

• Hardware - Procesadores lógicos: 4. Memoria física: 128 GB.

• Hardware - NUMA Config - Nodo: 0 Estado: ONLINE Programadores en línea: 4 Programadores fuera de línea: 0 Grupo de procesadores: 0 Nodo de memoria: 0 Memoria VAS reservada GB: 281

• Último reinicio del servidor - Okt 1 2017 2:21 PM

• Nombre del servidor: BWINPDB \ INFOR

• Servicios

  • Servicio: SQL Server (INFOR) se ejecuta bajo la cuenta de servicio NT Service \ MSSQL $ INFOR. Última hora de inicio: Okt 1 2017 2:22 PM. Tipo de inicio: Automático, actualmente en ejecución.

  • Servicio: SQL Server-Agent (INFOR) se ejecuta bajo la cuenta de servicio NT Service \ SQLAgent $ INFOR. Última hora de inicio: no se muestra. Tipo de inicio: Automático, actualmente en ejecución.

• SQL Server Last Restart - Okt 1 2017 2:22 PM

• Servicio SQL Server - Versión: 13.0.4001.0. Nivel de parche: SP1. Edición: Edición estándar (64 bits). AlwaysOn Enabled: 0. Estado de AlwaysOn Mgr: 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 ...

EDITAR:

Ya he estudiado esa guía de mejores prácticas con respecto a la configuración del servidor SQL con VMware, y hemos establecido la mayor parte de acuerdo con este documento. Sin embargo, hyperthreading no está activado y NUMA no está activo en el host vmware. Sin embargo, SQL Server está configurado en NUMA.

EDITAR:

He emitido RECONFIGURE después de establecer el umbral para el paralelismo a 50, también mi configuración MAXDOP no estaba configurada.

También verifiqué con nuestro administrador de vmware, parece que estaba mal informado. Nuestras CPU están configuradas a 2.6GHz, no a 4.6 GHz. He corregido esa información anterior.

EDITAR:

Intentamos establecer alguna red relacionada de acuerdo con este vmwarekb y esta guía . También agregamos 4 núcleos más a la VM. El uso de la CPU se mantuvo igual.

Como se discutió la última vez que hizo esta pregunta , su espera principal es ASYNC_NETWORK_IO. SQL Server está sentado esperando que la máquina en el otro extremo de la tubería digiera la siguiente fila de resultados de la consulta.

Obtuve esta información de los resultados de las estadísticas de espera de sp_Blitz (gracias por pegar eso):

1 - ASYNC_NETWORK_IO: 225.9 horas de espera, 143.5 minutos de tiempo de espera promedio por hora, 0.2% de espera de señal, 2146022 tareas de espera, 378.9 ms de tiempo de espera promedio.

No salgas a la solución de problemas de los hilos de la CPU, eso no está relacionado. Concéntrese en su tipo de espera principal y las cosas que causarían ese tipo de espera.

Para solucionar este problema, ejecute sp_WhoIsActive o sp_BlitzFirst (descargo de responsabilidad: soy uno de los autores de eso), los cuales enumerarán las consultas que se están ejecutando actualmente. Mire la columna de información de espera, encuentre las consultas que esperan a ASYNC_NETWORK_IO y mire las aplicaciones y servidores desde los que se ejecutan.

A partir de ahí, puedes probar:

• Verificando si esos servidores de aplicaciones tienen poca potencia (como si están al máximo en la CPU o paginación en el disco) y sintonícelos
• Trabajando con los desarrolladores de la aplicación para ver si están procesando fila por fila en los resultados (como cada fila que regresa de SQL Server, la aplicación se apaga y procesa un poco antes de solicitar la siguiente fila de resultados)
• Trabajar con los desarrolladores de aplicaciones para seleccionar menos datos (como menos filas o menos columnas si no necesitan todos los datos; a veces se ve esto cuando la gente accidentalmente hace un SELECCIONAR * y devuelve más datos de los que necesitaban, o solicitan todas las filas cuando realmente solo necesitan las 1000 mejores)

Actualice con sp_WhoIsActive : en la captura de pantalla de sp_WhoIsActive que publicó, tiene un par de consultas que esperan en ASYNC_NETWORK_IO. Para aquellos, consulte las instrucciones anteriores.

En el resto de las consultas, mire la columna "estado" de sp_WhoIsActive: la mayoría de ellas están "durmiendo". Eso significa que no están funcionando en absoluto, están esperando que las aplicaciones en el otro extremo de la tubería envíen su próximo comando. Tienen transacciones abiertas (vea la columna "open_tran_count") pero no hay nada que SQL Server pueda hacer para acelerar una transacción inactiva. Estas consultas han estado abiertas durante más de cuarenta minutos (la primera columna en sp_WhoIsActive. Simplemente ya no están haciendo nada. Tienes que hacer que esas personas confirmen sus transacciones y cierren sus conexiones. Esto no es un problema de ajuste de rendimiento.

Todo lo que estamos viendo aquí apunta a un escenario en el que estamos esperando la aplicación.

Para responder mi propia pregunta. ASYNC_NETWORK_IO en realidad no era el verdadero problema. Solucionamos nuestro problema de rendimiento siguiendo esta guía para cargas de trabajo sensibles a la latencia:

Mejores prácticas para el ajuste del rendimiento de cargas de trabajo sensibles a la latencia en máquinas virtuales de vSphere

Marqué la configuración que aplicamos a nuestro sistema con color amarillo aquí:

Creo que las configuraciones con el mayor impacto fueron la configuración numa y la sensibilidad de latencia de configuración a alta . Lo que ambos requieren explícitamente asignar / reservar núcleos físicos de CPU y RAM para la VM.

También agregamos más núcleos a la VM y ahora necesitamos actualizar nuestra licencia de SQL Server de Standard a Enterprise.

Parece que Windows informa que la velocidad de reloj de sus núcleos de CPU de 4.6Ghz aparentemente es de 2.6Ghz ... Ejecutaría una herramienta como CPU-Z para verificar a qué velocidad realmente se están ejecutando, y luego vería cómo cambiar la configuración de energía en tanto Windows como el BIOS / Management OS para deshabilitar cualquier configuración de ahorro de energía que pueda estar acelerando los núcleos a una velocidad menor.