Tenemos una única instancia de SQL Server 2016 SP1 ejecutándose en una máquina virtual VMware. Contiene 4 bases de datos, cada una para una aplicación diferente. Esas aplicaciones están todas en servidores virtuales separados. Ninguno de ellos está en uso de producción todavía. Sin embargo, las personas que prueban las aplicaciones informan problemas de rendimiento.
Estas son las estadísticas del servidor:
- 128 GB de RAM (110 GB de memoria máxima para SQL Server)
- 4 núcleos a 4,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
- asd
Los usuarios realizan el acceso de pantalla única a través de una aplicación ERP basada en C ++.
Cuando hago una prueba de esfuerzo del SQL Server con Microsoft ostressutilizando muchas consultas pequeñas o una consulta grande, obtengo el máximo rendimiento. La única limitación es el cliente, porque no puede responder lo suficientemente rápido.
Pero cuando apenas hay usuarios, el SQL Server apenas está haciendo nada. Sin embargo, las personas tienen que esperar para siempre para guardar cualquier cosa en la aplicación.
De acuerdo con la consulta " Dime dónde duele " de Paul Randal , el 50% de todos los eventos de espera son ASYNC_NETWORK_IO.
Esto podría significar un problema de red o un problema de rendimiento con el servidor de aplicaciones o el cliente. Ninguno de los dos está utilizando de forma remota sus recursos a su máxima capacidad. La mayoría de las veces la CPU es de alrededor del 26% en todas las máquinas (Cliente, servidor de aplicaciones, servidor de base de datos).
La latencia de la conexión de red es de alrededor de 1-3 ms. El IO del servidor de base de datos tiene una velocidad máxima de escritura de 20 MB / s durante el uso normal con la aplicación (el promedio es de 7 a 9 MB / s). Cuando hago una prueba de esfuerzo, obtengo un máximo de 5 GB / s.
El tamaño de la memoria caché del búfer es de 60 GB para la base de datos de nuestro sistema ERP, 20 GB para nuestro software de financiación, 1 GB para el software de garantía de calidad, 3 GB para el sistema de archivo de documentos.
Le di a la cuenta de SQL Server el derecho de usar la inicialización instantánea de archivos . Eso no aumentó el rendimiento en lo más mínimo.
La esperanza de vida de la página es de alrededor de 15k + durante el uso normal. Cae a alrededor de .05k durante el final de las pruebas de estrés pesado, que es de esperar. Los lotes / seg son alrededor de 2-8k, dependiendo de la carga de trabajo.
Yo diría que la aplicación ERP está mal escrita, pero no puedo porque todas las aplicaciones están afectadas. Incluso con una carga de trabajo mínima.
Sin embargo, no puedo determinar qué está causando esto. ¿Hay algún consejo, sugerencias, tutoriales, aplicaciones, documentos de mejores / peores prácticas o cualquier otra cosa que tengan en mente sobre este problema?
Estos son los resultados de sp_BlitzFirst:
Lo corrí 600 segundos. Lo comencé durante una gran carga de trabajo de la aplicación. 1/3 del tiempo es ASYNC_NETWORK_IO. También he probado la conexión de red con NTttcp, PsPing, ipferf3, y pathping. Nada inusual. Los tiempos de respuesta son como máximo 3 ms, promedio 0.3 ms. El rendimiento es de alrededor de 1000 MB / s.
Mi investigación siempre resulta ASYNC_NETWORK_IOser la espera número uno.
Investigamos el resultado de deshabilitar la Large-Receive-Offloadfunción en VMware. Todavía estamos probando, pero los resultados parecen inconsistentes. Nuestro primer 'punto de referencia' resultó en una duración de 19 minutos (el resultado máximo es de 13 minutos, lo que solo se logra cuando la aplicación se ejecuta en la VM con el propio SQL Server). El segundo resultado es de 28 minutos, lo cual es realmente malo.
El primer resultado de nuestro 'punto de referencia' fue de 19 minutos. Lo que es bueno. Debido a que el resultado principal fue de 13 minutos (que solo se puede lograr cuando los parámetros de la aplicación en la VM con el propio SQL Server). Esto sugiere fuertemente algún problema relacionado con la red. O un problema con la configuración de VMware.
Actualmente estoy perdido en qué métodos usar, para clavarlo en el cuello de botella.
El máximo rendimiento con la aplicación solo se puede lograr cuando la aplicación se ejecuta en la VM con el propio SQL Server. Si la aplicación se ejecuta en cualquier otra máquina virtual o escritorio virtual, la duración de nuestro punto de referencia se triplica (de 13 minutos a 40 minutos o más). Todos los puntos finales (VM de SQL Server, VM del servidor de aplicaciones y el Escritorio virtual) están utilizando el mismo hardware físico. Hemos movido todos los demás puntos finales a otro hardware.
EDITAR: Parece que el problema ha vuelto. Después de configurar el modo de ahorro de energía de equilibrado a alto rendimiento, en realidad mejoramos drásticamente los tiempos de respuesta. Pero hoy ejecuté sp_BlitzFirst nuevamente, con una muestra de 300 segundos. Este es el resultado:
Muestra más segundos de tiempo de espera para ASYNC_NETWORK_IO que los segundos que se ejecutó sp_blitzfirst.
fuente