Medición mejorada de la limitación de la CPU

Ha pasado un año y medio desde que implementamos la característica de dimensionamiento de CPU de contenedores consciente de la limitación para IBM Turbonomic, y ha captado bastante atención, por una buena razón. Como se ilustra en nuestra primera entrada en el blog, establecer el límite de CPU incorrecto está dañando silenciosamente el rendimiento de su aplicación y literalmente funciona según lo diseñado.

Turbonomic visualiza las métricas de limitación y, lo que es más importante, tiene en cuenta la limitación al recomendar el dimensionamiento del límite de CPU. No solo podemos exponer este asesino silencioso del rendimiento, sino que Turbonomic prescribirá el valor límite de CPU para minimizar su impacto en el rendimiento de su aplicación en contenedores.

En esta nueva publicación, vamos a hablar sobre una mejora significativa en la forma en que medimos el nivel de limitación. Antes de esta mejora, nuestro indicador de limitación se calculó en función del porcentaje de períodos limitados. Con tal medición, se subestimó la limitación para aplicaciones con un límite de CPU bajo y se sobreestimó para aquellas con un límite de CPU alto. Eso resultó en evaluar las aplicaciones de alto límite de manera demasiado drástica, ya que ajustamos nuestra toma de decisiones hacia las aplicaciones de bajo límite para minimizar la limitación y garantizar el rendimiento.

En esta mejora reciente, medimos la limitación en función del porcentaje de tiempo limitado. En esta publicación, le mostraremos cómo funciona esta nueva medición y por qué corregirá tanto la subestimación como la sobreestimación mencionadas anteriormente:

• Breve revisión de la limitación de la CPU

• La forma antigua o con sesgo: medición de la limitación basada en períodos
• La nueva forma o sin sesgo: medición de limitación basada en el tiempo
• Resultados de una evaluación comparativa
• Lanzamiento

En este video de demostración, puede ver una ilustración similar de la limitación. Ahí hay una aplicación de contenedor de subproceso único con un límite de CPU de 0.4 núcleos (o 400 m). El límite de 400 m en Linux se traduce a una cuota de CPU cgroup de 40ms por 100ms, que es el período de aplicación de cuotas predeterminado en Linux que Kubernetes adopta. Eso significa que la aplicación solo puede usar 40 ms de tiempo de CPU en cada período de 100 ms antes de que se limite durante 60 ms. Esto se repite cuatro veces para una tarea de 200 ms (como la que se muestra a continuación) y finalmente se completa en el quinto período sin que se limite. En general, la tarea de 200 ms tarda 100 * 4 + 40 = 440 ms, más del doble del tiempo de CPU real necesario:

Linux proporciona las siguientes métricas relacionadas con la limitación, que cAdvisor monitorea y entrega a Kubernetes:

Desplazar para ver la tabla completa

Como se mencionó al principio, solíamos medir el nivel de limitación como el porcentaje de períodos ejecutables que están limitados. En el ejemplo anterior, eso sería 4/5 = 80 %.

Hay un sesgo significativo con esta medición. Consideremos una segunda aplicación contenedora que tiene un límite de CPU de 800 m, como se muestra a continuación. Una tarea con un tiempo de procesamiento de 400 ms ejecutará 80 ms y luego se limitará durante 20 ms en cada uno de los primeros cuatro períodos de aplicación de 100 ms. Luego se completará en el quinto período. Con la forma actual de medir el nivel de limitación, se llegará al mismo porcentaje: 80 %. Pero está claro que esta segunda aplicación sufre mucho menos que la primera aplicación. Se limita por solo 20 ms * 4 = 80 ms en total: solo una fracción de los 400 ms de tiempo de ejecución de la CPU. El nivel de limitación del 80 % medido actualmente es demasiado alto para reflejar la verdadera situación de esta aplicación.

Necesitábamos una mejor forma de medir la limitación, y la creamos:

Con el nuevo método, medimos el nivel de limitación como el porcentaje de tiempo limitado en comparación con el tiempo total entre el uso de la CPU y la limitación. Estas son las nuevas mediciones de las dos aplicaciones anteriores:

Estos dos números (55 % y 17%) tienen más sentido que el 80 % original. No solo son dos números diferentes que distinguen los dos escenarios de aplicación, sino que sus respectivos valores también reflejan de manera más adecuada el verdadero impacto de la limitación, como quizás podría visualizarse en los dos gráficos. Intuitivamente, la nueva medición puede interpretarse como cuánto se puede mejorar/reducir el tiempo total de la tarea eliminando la limitación. Para la primera aplicación, podemos reducir el tiempo total de la tarea en 240 ms (55 % del total). Para la segunda aplicación, es solo el 17 % si nos deshacemos de la limitación, no tan significativa como la primera aplicación.

A continuación, veremos algunos datos para comparar las mediciones de limitación calculadas utilizando los períodos de limitación frente a la versión basada en el tiempo.

En el caso de un contenedor con límites bajos de CPU, la medición basada en el tiempo muestra porcentajes de limitación mucho más altos en comparación con la versión anterior, que solo utiliza períodos de limitación, tal y como era de esperar.

A medida que aumentan los límites de la CPU, las mediciones basadas en el tiempo reflejan nuevamente con precisión porcentajes de limitación más bajos. Por el contrario, la versión anterior muestra un porcentaje de limitación mucho mayor, lo que puede provocar un cambio de tamaño agresivo a pesar de que el límite de CPU es suficientemente alto.

Esta nueva medición de limitación está disponible desde la versión 8.7.5 de IBM Turbonomic. Además, en la versión 8.8.2, también permitimos a los usuarios personalizar la tolerancia máxima a la limitación para cada aplicación individual o grupo de aplicaciones, ya que reconocemos plenamente que diferentes aplicaciones tienen diferentes necesidades en cuanto a tolerar la limitación. Por ejemplo, las aplicaciones sensibles al tiempo de respuesta, como las aplicaciones de servicios web, pueden tener una tolerancia más baja, mientras que las aplicaciones por lotes, como los grandes trabajos de machine learning, pueden tener una tolerancia mucho mayor. Ahora, los usuarios pueden configurar el nivel deseado como quieran.