Ha pasado un año y medio desde que implementamos la función de dimensionamiento de CPU de contenedor consciente de la velocidad para IBM Turbonomic, y ha captado conveniente atención, por una buena razón. Como se ilustra en nuestra primera publicación de blog, establecer un orilla de CPU incorrecto está acabando silenciosamente con el rendimiento de su aplicación y, textualmente, funciona como se diseñó.
Turbonomic visualiza las métricas de acotación y, lo que es más importante, tiene en cuenta la acotación al advertir el tamaño del orilla de la CPU. No solo podemos exponer este diabólico silencioso del rendimiento, Turbonomic prescribirá el valencia orilla de la CPU para minimizar su impacto en el rendimiento de su aplicación en contenedores.
En esta nueva publicación, vamos a charlar sobre una mejoría significativa en la forma en que medimos el nivel de velocidad. Ayer de esta mejoría, nuestro indicador de acotación se calculaba en función del porcentaje de períodos de acotación. Con tal medida, se subestimó la acotación para aplicaciones con un orilla de CPU bajo y se sobreestimó para aquellas con un orilla de CPU parada. Eso resultó en evaluar las aplicaciones de orilla parada de guisa demasiado agresiva, ya que ajustamos nuestra toma de decisiones con destino a las aplicaciones de orilla bajo para minimizar la acotación y avalar su rendimiento.
En esta mejoría flamante, medimos la acotación en función del porcentaje de tiempo establecido. En esta publicación, le mostraremos cómo funciona esta nueva medida y por qué corregirá tanto la subestimación como la sobreestimación mencionadas anteriormente:
Breve revisión de la acotación de la CPU La forma antigua/sesgada: medición de la acotación basada en el período La forma nueva/imparcial: medición de la acotación basada en el tiempo Resultados de la evaluación comparativa Impulso
Breve revisión de la velocidad de la CPU
Si ve este video de demostración, puede ver una ilustración similar de acotación. Allí hay una aplicación de contenedor de un solo subproceso con un orilla de CPU de 0,4 núcleos (o 400 m). El orilla de 400 m en Linux se traduce en una cuota de CPU de cgroup de 40 ms por 100 ms, que es el período de cumplimiento de cuota predeterminado en Linux que adopta Kubernetes. Eso significa que la aplicación solo puede usar 40 ms de tiempo de CPU en cada período de 100 ms ayer de que se acelere por 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 botellín período sin acotación. En genérico, la tarea de 200 ms tarda 100 * 4 + 40 = 440 ms en completarse, más del doble del tiempo de CPU efectivo necesario:
Linux proporciona las siguientes métricas relacionadas con la velocidad, que cAdvisor monitorea y envía a Kubernetes:
Desplácese para ver la tabla completa
La forma antigua/sesgada: medición de acotación basada en períodos
Como se mencionó al principio, solíamos calibrar el nivel de acotación como el porcentaje de períodos ejecutables que están limitados. En el ejemplo precursor, eso sería 4/5 = 80%.
Hay un sesgo significativo con esta medida. Considere una segunda aplicación contenedora que tenga un orilla de CPU de 800 m, como se muestra a continuación. Una tarea con un tiempo de procesamiento de 400 ms se ejecutará 80 ms y luego se acelerará durante 20 ms en cada uno de los primeros cuatro períodos de aplicación de 100 ms. Luego se completará en el botellín período. Con la forma contemporáneo de calibrar el nivel de estrangulamiento, llegará al mismo porcentaje: 80%. Pero claramente, esta segunda aplicación sufre mucho menos que la primera aplicación. Se acelera solo durante 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 acotación del 80 % medido actualmente es demasiado parada para reflectar la verdadera situación de esta aplicación.
Necesitábamos una forma mejor de calibrar la acotación y la creamos:
La forma nueva/imparcial: Medición de estrangulamiento basada en el tiempo
Con la nueva forma, medimos el nivel de acotación como el porcentaje de tiempo establecido frente al tiempo total entre el uso de la CPU y la acotación. Aquí están las nuevas medidas de las dos aplicaciones anteriores:
Desplácese para ver la tabla completa
Estos dos números, 55 % y 17 %, tienen más sentido que el 80 % llamativo. No solo son dos números diferentes que diferencian los dos escenarios de aplicación, sino que sus títulos respectivos todavía reflejan de guisa más adecuada el definitivo impacto de la acotación, como quizás pueda visualizar en los dos gráficos. Intuitivamente, la nueva medida se puede interpretar como cuánto se puede mejorar/aminorar el tiempo total de la tarea eliminando la acotación. Para la primera aplicación, podemos aminorar el tiempo total de la tarea en 240 ms (55 % del total). Para la segunda aplicación, es solo un 17 % si nos deshacemos de la acotación, no tan significativa como la primera aplicación.
Resultados de la evaluación comparativa
A continuación, verá algunos datos para comparar las medidas de acotación calculadas utilizando los períodos de acotación frente a la lectura basada en el tiempo.
Para un contenedor con límites de CPU bajos, la medición basada en el tiempo muestra porcentajes de acotación mucho más altos en comparación con la lectura precursor que usa solo períodos de acotación, como se esperaba.
A medida que aumentan los límites de la CPU, las mediciones basadas en el tiempo nuevamente reflejan con precisión los porcentajes de acotación más bajos. Por el contrario, la lectura precursor muestra un porcentaje de acotación mucho más parada, lo que puede resultar en un redimensionamiento agresivo a pesar de que el orilla de la CPU es lo suficientemente parada.
Desplácese para ver la tabla completa
Liberar
Esta nueva medida de regulación ha estado arreglado desde la lectura 8.7.5 de IBM Turbonomic. Encima, en la lectura 8.8.2, todavía permitimos que los usuarios personalicen la tolerancia máxima de acotación para cada aplicación individual o clan de aplicaciones, ya que reconocemos completamente que las diferentes aplicaciones tienen diferentes micción en términos de tolerar la acotación. Por ejemplo, las aplicaciones sensibles al tiempo de respuesta, como las aplicaciones de servicios web, pueden tener una tolerancia más quebranto, mientras que las aplicaciones por lotes, como los grandes trabajos de enseñanza automotriz, pueden tener una tolerancia mucho veterano. Ahora, los usuarios pueden configurar el nivel deseado como quieran.
Obtenga más información sobre IBM Turbonomic.
