Etiquetas
Actualización: sigo estudiando el tema porque es muy raro, si pongo un proceso en bucle no consume el 100% de CPU, sino el 50%. Parece que hay un problema de medición (tanto localmente como lo que mide Amazon CloudWatch). Si descubro algo más lo pondré.
En enero de este año Amazon habilitó el uso general de sus nuevas instancias «m3» (las originales son m1). Además del almacenamiento SSD, estas instancias tienen -según ellos- más CPU (3 ECU vs 2 ECU de las m1). Para los servidores web de Menéame usamos instancias m1.medium, pero las m3.medium parecían más adecuadas, nos podíamos ahorrar alrededor del 50% del coste. No las cambié inmediatamente porque el espacio disponible en /mnt en las m3 es muy pequeño (sólo 4GB) y allí es donde generábamos los logs del NGInx.
Pero estos días Amazon también empezó a ofrecer almacenar los logs del balanceador de carga (ELB) en S3, por lo que habilté estos y deshabilité los generados por NGInx en las instancias. Así, ya no hacían faltan varias decenas de GB por cada 24 horas de funcionamiento de cada instancia y podíamos pasar a usar las instancias m3 sin ningún otro cambio. Lo hice a partir de las 12 de la noche, tal como es visible en el siguiente gráfico.
El línea verde muestra el número medio (por minuto) de llamadas a scripts PHP por segundo. La línea amarilla el porcentaje acumulado de uso de CPU, y la línea azul clara el numero de instancias web. Se puede ver claramente como a partir del cambio a m3, el uso de CPU se ha incrementado y también la necesidad de más instancias para servir el mismo número de ejecuciones por segundo.
Los resultados son claros, al menos para la ejecución de scripts webs, la m3 son bastantes menos potentes que las m1. Lo contrario de lo que afirma Amazon. Me sorprende mucho, sobre todo porque se trata de hardware nuevo con mucha más memoria cache (25 MB) que las anteriores m1 (que suelen tener 5-6MB).
Habrá que volver a las m1.
Agregado
Diferencia de carga de CPU entre una instancia m1.medium y m3.medium ejecutándose bajo las mismas condiciones. La primera es una m1, la siguiente una m3.
Ricardo Galli, de software 
Hola,
Me llama la atencion lo de los logs de nginx. Mis inquietudes son:
¿Has hecho pruebas de carga?
¿Tienes más metricas, red, io, etc, ademas del CPU y las conexiones?
¿Que pasa si en una instancia m1 deshabilitas los logs de nginx? Lo digo para comparar en total igualdad de condiciones, y entre una de las teorias mias, es que puede uses más CPU evitar hacer el IO de los logs.
Para inspiracion:
http://www.brendangregg.com/activebenchmarking.html
http://www.brendangregg.com/methodology.html
Saludos
@ae_bm
@alejandro
te respondí con las últimas dos gráficas que agregué. Y mira la actualización el principio, me parece que hay un error en las mediciones de CloudWatch.
De fet, a casa ens hem trobat una cosa semblant: un procés batch d’un parell d’hores sobre un parell d’instàncies m3.large i m3.xlarge on el celery no aconseguia ni d’enfora carregar la màquina. Pega un truc a nen Bernat, ell et podrà contar més.
Un problema que he observado en EC2 y puede estar relacionado con las métricas de CPU que comentas es lo que en herramientas de monitorización de Linux (top, por ejemplo) denominan «stolen CPU time», y que básicamente es el tiempo en que la CPU física no está siendo utilizada por tu instancia, sino por otras. Por ejemplo, en las instancias micro ese tiempo pasa fácilmente del 90% de la CPU, por lo que herramientas como top pueden reportar un uso de CPU de 10% o inferior y sin embargo la máquina va «a rastras». En Cloudwatch normalmente no se tiene en cuenta (esa misma máquina al 10% cloudwatch la reportaría como 100%, al menos hasta lo que yo he observado), pero es posible que esto dependa del tipo de instancia. Dependiendo del porcentaje de stolen time, el porcentaje reportado por cloud watch realmente corresponde a capacidades de procesamiento reales muy diferentes. Simplificando: un 100% de CPU en cloud watch con un stolen time de 0 es un 100% real de CPU, pero un 100% en cloud watch con 50% de stolen time es realmente sólo la mitad de capacidad de procesamiento.
Es posible incluso que en las m3 (que no he probado) hayan ajustado el valor reportado por cloudwatch… En definitiva, la monitorización en EC2 y similares es compleja y según mi experiencia es difícil extraer conclusiones de la comparación entre distintos tipos de instancia, cargas, etc Posiblemente lo mejor sea estudiar el rendimiento «real», en definitiva, peticiones por segundo vs coste, para ver que tipo de instancia ofrece mejores resultados. Estaré pendiente de las actualizaciones de este post, sin duda interesante!