¿Por qué mi servidor SQL Azure es tan lento?


10

Actualmente tenemos una VM que tiene muy poca potencia y estamos proponiendo pasar a una VM de Azure con mejores especificaciones. El problema es que la máquina virtual de Azure es mucho más lenta que la máquina virtual original, aunque es de una especificación más alta.

El servidor original es una VM de 2 núcleos con 2 GB de memoria que también es un servidor web. Está ejecutando Microsoft SQL Server Web Edition 2008 R2 y debido a que este servidor se usa para otras cosas, hemos tenido que limitar la memoria máxima del servidor en SQL Server a 512 MB .

El nuevo servidor es una máquina virtual de 4 núcleos con 7 GB de memoria que es solo un servidor de base de datos. Está ejecutando Microsoft SQL Server Standard Edition 2008 R2 y no hemos limitado la cantidad de memoria que SQL Server puede usar.

Este es uno de los dos servidores configurados en un entorno reflejado, pero la base de datos en la que estoy ejecutando las pruebas no está reflejada. Las otras bases de datos en este servidor no reciben mucho tráfico en este momento (de hecho, el Monitor de actividad no muestra actividad en los otros DB mientras ejecutaba estas pruebas).

Me doy cuenta de que un problema con las máquinas virtuales de Azure es que los discos duros son un recurso de red, por lo que sería la fuente de la desaceleración, pero aún es más lenta incluso cuando se muestran 0 lecturas físicas en las estadísticas de E / S.

He seguido los consejos de ajuste en esta página en la máquina virtual de Azure, que incluyen el despojo de los discos (dos discos por unidad) y el archivo de registro y de datos en unidades separadas.

Lo único que no he hecho es habilitar la compresión de páginas, limitar el crecimiento automático en la base de datos y mover el registro de errores del servidor SQL y rastrear directorios de archivos a discos de datos. Tampoco lo he hecho en el servidor anterior.

El servidor anterior no ha realizado ninguno de estos ajustes y los archivos de registro y datos están en la misma unidad que no está rayada.

La base de datos en el servidor actual es de 65 GB (45 datos y 20 registros) que era un poco demasiado grande para transferir al nuevo servidor, así que estoy probando en un DB más pequeño (6 datos y 13.5 registros)

Los resultados en el servidor anterior son CPU time = 1311 ms, elapsed time = 1057 ms.y en el servidor nuevo. CPU time = 1281 ms, elapsed time = 2525 ms. Esa es solo una ejecución, pero los resultados son representativos de lo que normalmente estoy viendo.

El nuevo servidor parece tener constantemente un tiempo transcurrido significativamente más largo que el tiempo de CPU. ¿Es eso un problema y hay algo que pueda hacer para localizar qué lo está causando?

¿Qué otros pasos puedo tomar para averiguar por qué este servidor funciona tan lentamente cuando parece que debería ser más rápido que el servidor anterior?


1
Maxdop 1? ¿Comparó los planes de ejecución, tomó las estadísticas de espera antes y después y verificó el bloqueo?
Aaron Bertrand

1
¿Cuántas unidades de datos? Con el almacenamiento estándar de blobs en páginas, cada unidad está limitada a menos de 300 IOPS en el nivel básico o 500 en estándar, que es mucho menos que un disco giratorio local. Es imprescindible tener tantas unidades (vhd) como sea posible para maximizar el IOPS y el ancho de banda. Puede usar los espacios de almacenamiento de Windows para evitar la necesidad de crear un archivo de datos separado en cada unidad.
Dan Guzman

El nuevo servidor tiene 4 VHD divididos en dos unidades, por lo que tengo 1000 IOPS para registros y 1000 IOPS para datos.
Steve Kaye

Un VHD de almacenamiento de blog de página estándar solo proporciona un ancho de banda de aproximadamente 30 MB / seg debido a la limitación, por lo que solo es un agregado de 60 MB / seg. Considere crear 14 VHD de datos para hasta 420 MB / seg y dividir entre todos.
Dan Guzman

Solo puedo tener 8 discos, ya que es una instancia A3, así que tendría que actualizar a A4 para hacer eso, que es el doble del precio. Sin embargo, no creo que este sea un problema de manejo, ya que las pruebas sobre todo tuvieron 0 lecturas físicas enumeradas en las estadísticas de IO.
Steve Kaye

Respuestas:


2

Por lo que vale, terminé cambiando la VM en Azure de tipo A a tipo D y luego adjunté otro disco y moví el TEMPDB a ese disco. Entonces, mi VM final ahora es un D2 Standard con 7 GB de RAM y tres discos de datos, uno para los archivos MDF, otro para los archivos LDF y el nuevo disco TEMPDB.

Dejé de tratar de entender con el A3 algunas cosas que mencionaste y simplemente actualicé la máquina virtual. Incluso pasé de A2 a A3 y, aunque encontré algunas mejoras, terminé cambiando a una VM D2.

En el documento que indicó, Microsoft recomienda un D3 para Enterprise Edition o D2 para Web o Standard Edition, y el uso de Premium Storage, entre otras cosas en la lista de verificación al comienzo del documento.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.