Calculo de “ahorro” de crédito burstable EC2 t2.medium

Estoy usando una instancia de T2.medium. Un tercio del día estoy haciendo cálculos estadísticos intensivos y calculé que el rest 2/3 del tiempo “ganaría” créditos a una tasa de 24 por hora.

Pero eso no está sucediendo. Este es mi uso los últimos dos días:

Uso de crédito de la CPU

Y esta es mi cuenta de crédito:

Saldo de crédito de la CPU

No lo había usado durante (más de) un día hasta ayer a las 6 p.m. Lo uso intensivo durante cinco horas. Entonces esperaría que mi “cuenta” acumule 24 créditos por hora, pero durante 9-10 horas casi no pasa nada, luego se acumula como se esperaba durante 9 horas y luego se vuelve plana nuevamente.

No puedo entender qué está pasando y si es un error. ¿Alguien tiene una buena explicación?

EDITAR: He incluido una semana de actividad a continuación. Todavía no puedo descifrar el algoritmo:

Semana de uso de créditos de CPU Semana de saldo de crédito de la CPU

Actualización: las reglas utilizadas para calcular los saldos de crédito de la CPU t2 parecen haber cambiado de tal manera que el problema que provoca esta pregunta ya no debería tener un impacto.

Según los comentarios de los clientes, hemos actualizado las instancias de T2 con una nueva política de asignación de créditos de CPU que es igual o mejor que la política anterior en todos los casos.

Ahora, los Créditos de CPU ganados no caducan hasta que la instancia finaliza o se detiene. Una instancia de T2 aún puede ganar hasta el mismo nivel máximo permitido por el tamaño de la instancia. El CPUCreditBalance ahora boostá cada vez que el CPUCreditUsage actual esté por debajo de la línea de base y pueda crecer al máximo permitido para el tamaño de instancia.

https://forums.aws.amazon.com/ann.jspa?annID=5196

h / t: la semana pasada en AWS para la actualización.

La respuesta original sigue.


Esta pregunta me ha causado un poco de angustia mental en las últimas horas, porque los gráficos casi tienen sentido, según lo que sé sobre las instancias de t2. Casi, pero no del todo, y no pude identificar el problema. Esa es la peor clase. Particularmente, soy un gran admirador de la propuesta de valor que ofrecen las máquinas t2.

Pero finalmente descubrí qué está pasando aquí.

Hay un concepto de créditos de CPU que la documentación no parece explicar, pero las matemáticas funcionan, y la explicación se mantiene muy bien en las observaciones del mundo real:

Los créditos de CPU ganados más recientemente se gastan primero, no último.

¿Importa el orden? Lo hace.

Para probar, utilicé un t2.micro (principalmente porque tenía uno inactivo que había estado funcionando durante varios días, y necesitaba algo que hacer, y no quería que los créditos “iniciales” adicionales de una nueva instancia se nublaran las observaciones) pero todos los tipos de instancia en la clase t2 tienen un comportamiento similar.

A modo de fondo: en la clase t2, los créditos de CPU se obtienen a diferentes velocidades, pero los créditos de CPU se usan a la misma velocidad para todos los tipos de instancias de la clase:

Un crédito de CPU proporciona el rendimiento de un núcleo de CPU completo durante un minuto.

El t2.micro y el t2.small tienen solo un núcleo, por lo que pueden grabar hasta 1 crédito por minuto o 60 créditos por hora, al 100% de utilización de la CPU. El t2.medium y t2.large son de doble núcleo, por lo que pueden grabar hasta 2 créditos por minuto, o 120 créditos por hora, al 100% de utilización de CPU en ambos núcleos.

Si 1 crédito = 100% de 1 núcleo durante 1 minuto, entonces 1 crédito también equivale al 20% de 1 núcleo durante 5 minutos. Como el intervalo del gráfico de Cloudwatch está en incrementos de 5 minutos, configuré la siguiente prueba:

En un t2.micro que ha estado funcionando durante varias semanas sin carga, instalé lookbusy , una práctica utilidad que le permite hacer que una máquina se “vea ocupada” con los parámetros que especifique, por ejemplo, mantener la CPU al 20% de utilización. .

$ screen -S eat_cpu $ ./lookbusy -v -c 20 -r fixed 

Esto hace exactamente lo que esperaría, quemando 1 CPU de crédito cada 5 minutos. El gráfico “Uso de créditos de CPU” confirma esto, mostrando que se usa 1 crédito cada 5 minutos. (El gráfico de utilización de la CPU, y top , ambos confirman el 20%).

Pero, ¿qué está pasando con mi saldo de crédito? Se está agotando con 1 crédito cada 5 minutos. Eso parece estar mal, ¿no? Quiero decir, sí, acabo de decir que esa es la cantidad que uso, pero … También se supone que estoy ganando 6 créditos por hora, así que solo debería agotar el saldo por una red de 0.5 créditos cada 5 minutos , ¿derecho?

Espera … revisando los números, otra vez: estoy ganando 6 por hora, gastando 12 por hora, entonces, sí … parece que debería ser una disminución neta de solo 6 por hora, no 12 … ¿derecho? Claramente, algo no cuadra como esperaba, porque mi balance definitivamente baja 12 por hora, y mi CPU definitivamente solo está funcionando al 20%.

Parece que no estoy ganando créditos para compensar mi uso. ¿Cómo es eso posible?

A no ser que…

Los créditos obtenidos sin usar de un intervalo dado de 5 minutos caducan 24 horas después de que se obtienen

Bueno, hace 24 horas, mi instancia estaba completamente inactiva. Durante esa hora, obtuve 6 créditos que … no usé (?). ¿No los estoy usando ahora? ¿No debería ser?

todos los créditos vencidos se eliminan del saldo de crédito de la CPU en ese momento, antes de que se agreguen los créditos recién obtenidos

Crud. ¿Podría esto estar relacionado? Esta hora, gané 6 créditos nuevos. Pero justo antes de eso, perdí 6 créditos de hace 24 horas. Luego gasté 12 créditos esta hora … así que mi saldo bajó 6, subió 6 y bajó 12 más. Bueno, eso explica el cambio de -12 por hora, pero …

¿Puede ser esa la razón?

Soy un lector voraz de documentación, así que sabía sobre el aspecto del crédito vencido … pero asumí desde el principio que esto no era más que el motivo por el que una instancia inactiva se encuentra cerca de su saldo máximo, y no tenía ningún otro significado. ¿Cómo podría? Si tengo menos del máximo (6 x 24 = 144 para un t2.micro), ¿cómo podría tener créditos para caducar?

Si mis créditos de hace 24 horas siempre cuentan en mi contra, ¿no tendería mi balanza a cero, independientemente de lo que haga?

A no ser que…

Después de dar vueltas durante la mayor parte de la noche mientras contemplaba deslizar montones de tokens imaginarios (que representan créditos de CPU) en una mesa imaginaria (que representa el tiempo) … me di cuenta de que la regla de “expiración” causaría exactamente el comportamiento que observamos, De forma contra intuitiva, los créditos no se gastan en el orden en que se obtienen (FIFO), sino en el orden inverso (LIFO).

Siguiendo esa línea de razonamiento, la explicación de lo que realmente está haciendo mi prueba de CPU del 20% es esta, donde la primera hora de mi prueba fue “hora 0” –

  | spends 6+6 credits | expire 6 credits test | earned this many | earned this many hour | hours before hour 0 | hours before hour 0 -----+---------------------+-------------------- 0 -1, -2 -24 1 -3, -4 -23 2 -5, -6 -22 3 -7, -8 -21 4 -9, -10 -20 5 -11, -12 -19 6 -13, -14 -18 7 -15, -16 -17 

Y se encuentran en el medio.

Es esto genuino, o estoy adivinando? No estoy adivinando, y aquí está la evidencia:

Después de 8 horas, mi gráfico de uso de crédito de la CPU sigue siendo sólido, manteniéndome estable a 1 crédito por 5 minutos, pero después de las mismas 8 horas, el saldo de mi CPU finalmente comienza a agotarse a la tasa (más lenta) que esperaba originalmente: 0.5 créditos cada 5 minutos.

Aparentemente, mientras trabajaba hacia atrás en el tiempo, al gastar los créditos anteriormente ganados como “los más nuevos primero”, alcancé mis viejos créditos que estaban a punto de caducar, y finalmente llegué al punto en el que los usaba antes de que pudieran vencer. Ahora, no tengo créditos que tengan 24 horas de antigüedad, por lo que no hay créditos vencidos, así que ya no pierdo créditos antes de que se obtengan nuevos créditos. Ahora puedo mantener los 6 que gano por hora, porque agotó los viejos, disminuyendo el impacto neto en mi saldo de crédito al nivel esperado.

Esto explica la única reserva que tenía sobre los gráficos en la pregunta: ¿por qué, cuando la utilización disminuye, tarda tanto tiempo en recuperarse?

La respuesta TL; DR es la siguiente: el saldo no se recupera inmediatamente, después de una explosión de gran utilización, porque todavía tiene créditos no utilizados de las 24 horas anteriores, que están cancelando sus créditos recién ganados, hasta que alcanza el punto en momento en que no tiene créditos no utilizados de 24 horas de antigüedad. Cuando eso sucede, su saldo de crédito aumenta nuevamente.

Deje la instancia completamente inactiva durante 24 horas y eventualmente verá que el equilibrio de manera constante (en su mayor parte) vuelve a boost al máximo, como se esperaba. Cualquier cosa menos de 24 horas completamente inactiva hará que su balanza permanezca perpetuamente en algún lugar por debajo del máximo.

Mi script de prueba eventualmente agotó mi saldo de crédito casi todo el camino. Cuando maté el proceso de consumo de la CPU, el saldo de crédito comenzó a recuperarse inmediatamente , a la tasa esperada de 6 créditos por hora.

Por el contrario, cuando tomé una máquina diferente que había visto una baja utilización durante 24 horas, y ejecuté su CPU al 100% durante unos minutos, luego volví a inactivo, los créditos no comenzaron a acumularse de forma inmediata … siendo compensado por viejos, vencidos.

Las citas son de http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html .