
Estamos teniendo un problema de rendimiento que no podemos explicar con nuestro entorno VMWare y espero que alguien aquí pueda ayudar. Tenemos una aplicación web que utiliza un backend de bases de datos. Tenemos una configuración de clúster SQL 2005 en Windows 2003 R2 entre un nodo físico y un nodo virtual. Ambos servidores físicos son 2950 idénticos con 2 CPU Xeaon x5460 Quad Core y 64 GB de memoria, 16 GB asignados al sistema operativo. Estamos utilizando un iSCSI San para todos los discos del clúster. El problema es que, cuando se utiliza la aplicación bajo pruebas de estrés repetidas que agregan CPU a los nodos del clúster, el nodo físico escala de 1 pCPU a 8 pCPU, lo que significa que vemos aumentos continuos en el rendimiento. Al probar el nodo que ejecuta Vsphere, tenemos el rendimiento esperado del 12% por ser virtual, pero aún escalamos de 1 vCPU a 4 vCPU como el físico, pero más allá de este rendimiento cae, cuando llegamos a 8 vCPU estamos viendo rendimiento. números peores que con 4 vCPU. Nuevamente, ambos nodos están configurados de manera idéntica en términos de hardware, sistema operativo invitado, configuraciones SQL, etc. y no hay más tráfico que el de prueba en el sistema. No hay otras máquinas virtuales en el servidor virtual, por lo que no debería haber competencia por los recursos. Nos hemos puesto en contacto con VMWare para obtener ayuda, pero en realidad no han sugerido cosas como configurar la afinidad del procesador SQL que, si bien sería útil, tendría el mismo efecto neto en cada cuadro y no debería cambiar nuestros resultados en lo más mínimo. Hemos analizado todas las guías de ajuste de SQL de VMWare con respecto a VSphere sin ningún beneficio, ¡por favor ayuda!
Respuesta1
Dudo en ingresar esto como respuesta porque no tengo mucho apoyo concreto para esto, pero podría ser la causa del problema que estás viendo. He escuchado antes (yesteLa página lo admite) que la programación de CPU de VMWare tiene más dificultades cuando una VM tiene varias CPU. Para una máquina virtual con una sola CPU, solo es necesario programar un único procesador host. Sin embargo, cuando una VM tiene más de uno, VMWare tiene que programar varios procesadores para que estén disponibles para la VM, lo que puede llevar más tiempo. Esto sería cada vez más difícil de programar a medida que aumenta la cantidad de CPU de VM, lo que significa que la VM en realidad ve un peor rendimiento porque le resulta más difícil asignarle tiempo de procesador.
Además, releí su último comentario y últimamente también he tenido problemas con la contención en vSphere. Otra cosa que quizás quieras probar (si aún no lo has hecho) es aumentar la asignación de recursos para esta VM, aunque sea la única VM que existe en este momento.
Respuesta2
Tienes una configuración bastante ordenada aquí ;-)
¿Están las vCPU utilizadas a su máxima capacidad? ¿Qué le dicen los gráficos de espera de CPU, CPU lista y uso de CPU?
A medida que se agregan más vCPU a una máquina virtual, se genera más sobrecarga en el sistema host para administrar las vCPU y asignarlas a la física. En algún momento, no obtendrá más rendimiento de una máquina virtual simplemente agregando más vCPU.
¿Verificó si hay un problema de rendimiento en iSCSI SAN? Verifique los gráficos de las solicitudes de lectura y escritura del disco y, por supuesto, las tasas de lectura y escritura del disco y compárelas con las del miembro del clúster físico.
Quizás algunos de los valores puedan indicarle la dirección correcta.
Respuesta3
Solo para aclarar, está utilizando una caja ESX de 8 núcleos (2 x 4) para alojar una única máquina virtual de 8 vCPU y no ve ninguna ganancia real de rendimiento para la quinta vCPU y las posteriores, ¿verdad? ¿Puedo preguntar por qué no estás utilizando el mismo host que un cuadro SQL físico? Está utilizando entre 5.000 y 6.000 dólares en licencias Enterprise Plus para lo que parece no ser ningún beneficio (incluso si no estuviera viendo problemas de rendimiento). No lo entiendo, lo siento.