3 votos

Rendimiento de Azure IO

Tenemos varias máquinas virtuales de Windows Server que utilizamos para el desarrollo y el control de calidad de .NET y Java. Azure me parece atractivo por las razones obvias, pero sobre todo por la oportunidad de reducir las horas no productivas dedicadas al mantenimiento del entorno.

Funcionalmente, después de limpiar los problemas de identificación del sistema con algunas de las aplicaciones (licencias, etc.) todo está bien, pero el rendimiento es algo escaso:
Nuestro sistema tarda unos 2 minutos en construir su solución cuando se ejecuta en Hyper-V o ESXi, pero la máquina Azure A3 está tardando hasta 12 minutos para realizar la misma construcción .
El monitor de recursos muestra que la mayor parte del tiempo la máquina está en espera de IO leyendo el disco.

¿Hay algo que deba hacer de forma diferente o debo esperar un mejor rendimiento de las máquinas locales en todos los casos?

4voto

yulia Puntos 16

Las máquinas virtuales de Azure se dimensionan en función de su memoria RAM y de los núcleos de la CPU, pero todos los tamaños carecen notablemente de rendimiento de almacenamiento, que siempre se convierte en el principal culpable, independientemente de cuántos núcleos y memoria se le dediquen a una máquina virtual.

Dos soluciones:

  • Para un uso normal, simplemente adjunta tantos discos de datos como sea posible a tu VM y configúralos en RAID 0 en el sistema invitado; la E/S está limitada a nivel de disco, por lo que más discos = más E/S. Utiliza esos discos para el trabajo real, no pongas nada más que el S.O. en el disco del sistema (que es la mejor práctica de todos modos). Esta estrategia no tiene costes adicionales, porque el almacenamiento de Azure se factura en función del espacio real utilizado: el número de discos virtuales y su tamaño aparente no importan en absoluto. (*)
  • Si usted realmente necesita rendimiento del disco, utilice almacenamiento premium .

(*) Si le preocupa el uso de RAID 0, no lo haga. Son discos virtuales, y su integridad ya está garantizada por la capa de almacenamiento subyacente. El RAID 0 sólo se utiliza para agruparlos en un único volumen lógico con mejor rendimiento.

1voto

voretaq7 Puntos 63415

Azure es un servicio compartido. Deberías esperar variaciones aleatorias de rendimiento basadas en la carga del hipervisor en el que estás ejecutando (sobre el que no tienes absolutamente ningún control), y una serie literalmente infinita de otros factores (sobre los que tampoco tienes control).

Si el rendimiento (y la consistencia) es crítico, aloja tu propio entorno, en tu propio hardware.

1voto

Jan Bühler Puntos 111

No deberías usar tu unidad c para las aplicaciones:

http://blogs.msdn.com/b/igorpag/archive/2014/10/23/azure-storage-secrets-and-linux-i-o-optimizations.aspx

La unidad C está optimizada para el tiempo de arranque, no para la alta IO.

Como cada disco tiene un límite de IOPS (normalmente 500/disco), puedes usar muchos de ellos (hasta 8 en A3) o usar una máquina de la serie d con SSD (D3: 12000IOPS). Ten en cuenta que tienes que usar el disco d que no garantiza la persistencia de los datos para tener velocidad de SSD:

http://azure.microsoft.com/blog/2014/10/06/d-series-performance-expectations

O puedes pagar $$$ y usar un blob de almacenamiento premium (~100$/Mes por 5000 IOPS) para tener un almacenamiento persistente.

0voto

urw7RSeeh8FR Puntos 11

Hemos trasladado todo nuestro entorno de producción a Azure hace unos 6 meses. Tenemos un servidor de compilación que ejecuta varias compilaciones diarias y, basándome en la duración de las tareas de compilación individuales de una compilación a otra, puedo decir que el "rendimiento" es bastante consistente. También puedo confirmar sus hallazgos de que los procesos que no utilizan múltiples núcleos (por ejemplo, la ejecución de pruebas unitarias) se ejecutan alrededor de 6 veces más lento en una VM Azure en comparación con un PC de desarrollo local.

En resumen, cuando estás ejecutando procesos en un solo núcleo, tu máquina local siempre superará a una VM de Azure. Creo que Azure es más adecuado para manejar tareas que implican múltiples núcleos (por ejemplo, una base de datos o un servidor web), porque puedes escalar fácilmente hacia arriba/hacia abajo los núcleos según sea necesario.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: