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?
fuente
Respuestas:
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.
fuente