Micrometics para tubería CI/CD

La integración continua/implementación continua (CI/CD) se ha convertido en un elemento central del desarrollo de software. Para garantizar versiones de software de alta calidad, se ejecutan pruebas de humo, pruebas de regresión, pruebas de rendimiento, análisis de código estático y escaneos de seguridad en la canalización de CI/CD. A pesar de todas estas medidas de calidad, aún aparecen OutOfMemoryError, picos de CPU, falta de respuesta y degradación en el tiempo de respuesta en el entorno de producción.

Este tipo de problemas de rendimiento surgen en producción porque en la canalización de CI/CD solo se estudian métricas de nivel macro como: métricas de calidad de código estático, cobertura de prueba/código, uso de CPU, consumo de memoria, tiempo de respuesta… En varios casos, estas macrométricas no son suficientes para descubrir problemas de rendimiento. En este artículo, revisemos las micrométricas que deben estudiarse en la canalización de CI/CD para entregar versiones de alta calidad en producción. También aprenderemos cómo obtener esta micrometría e integrarla en la canalización de CI/CD.

¿Cómo se pronostican los tsunamis?

Quizás se pregunte por qué el pronóstico de tsunamis está relacionado con este artículo. hay una relacion 😃. Una ola de mar normal viaja a una velocidad de 5 a 60 millas por hora, mientras que las olas de un tsunami viajan a una velocidad de 500 a 600 millas por hora. Aunque la ola de tsunami viaja a una velocidad de 10x – 100x de la velocidad de las olas normales, es muy difícil pronosticar olas de tsunami. Por lo tanto, las tecnologías modernas utilizan la micrometría para pronosticar las olas de los tsunamis.

diseño-sin-titulo-3.png

Fig: Dispositivo DART para detectar Tsunami

                         To forecast Tsunami, multiple DART (Deep-ocean Assessment and Reporting of Tsunami) devices are installed all throughout the world. This DART contains two parts:

una. Boya de superficie: dispositivo que flota en la parte superior del agua del océano.
b. Monitor de fondo marino: dispositivo que está estacionado en el fondo del océano

El agua del océano profundo tiene unos 6000 metros de profundidad. (20x de la torre más alta de San Francisco Sales Force). Cada vez que el nivel del mar sube más de 1 mm, DART lo detecta automáticamente y transmite esta información al satélite. Este aumento de 1 mm en el agua de mar es un indicador principal del origen de un tsunami. Me gustaría pedirle que haga una pausa aquí por un segundo y visualice una longitud de 1 mm en la escala de 6000 metros de profundidad del mar. No es nada, insignificante. Pero este análisis micrométrico es el que se utiliza para pronosticar Tsunamis.
**
¿Cómo pronosticar tsunamis de rendimiento a través de Micrometrics?**
Del mismo modo, hay pocos micrométricos que puede monitorear en su canalización de CI/CD. Estos micrométricos son indicadores principales de varios problemas de rendimiento que enfrentará en la producción. El aumento o la disminución de los valores de estas micrométricas son los grandes indicadores para el origen de los problemas de rendimiento.

  1. Rendimiento de la recolección de basura
  2. Tiempo medio de pausa del GC
  3. Tiempo máximo de pausa del GC
  4. Tasa de creación de objetos
  5. Tamaño máximo de almacenamiento dinámico
  6. Número de hilos
  7. Estados de subprocesos
  8. Grupos de subprocesos
  9. Memoria desperdiciada
  10. Recuento de objetos
  11. Recuento de clases

Estudiemos cada micrometría en detalle:

1. RENDIMIENTO DE RECOGIDA DE BASURA

La recolección de elementos no utilizados es la cantidad de tiempo que su aplicación dedica a procesar las transacciones de los clientes frente a la cantidad de tiempo que su aplicación dedica a la recolección de elementos no utilizados.

Digamos que su aplicación se ha estado ejecutando durante 60 minutos. En estos 60 minutos, se dedican 2 minutos a las actividades de la CG.
Significa que la aplicación ha gastado un 3,33 % en actividades de GC (es decir, 2/60 * 100)
Significa que el rendimiento de la recolección de basura es del 96,67 % (es decir, 100 – 3,33).

Cuando hay una degradación en el rendimiento del GC, es una indicación de algún tipo de problema de memoria. Ahora la pregunta es: ¿Cuál es el porcentaje de rendimiento aceptable? Depende de la aplicación y las demandas comerciales. Por lo general, uno debe apuntar a más del 98% de rendimiento.

2. TIEMPO PROMEDIO DE PAUSA EN LA RECOGIDA DE BASURA

Cuando se ejecuta el evento Garbage Collection, toda la aplicación se detiene. Debido a que Garbage Collection tiene que marcar todos los objetos en la aplicación, vea si esos objetos están referenciados por otros objetos, si no hay referencias, entonces tendrá que ser desalojado de la memoria. Entonces la memoria fragmentada tiene que ser compactada. Para realizar todas estas operaciones, la aplicación se pausará. Por lo tanto, cuando se ejecuta la recolección de basura, el cliente experimentará pausas/retrasos. Por lo tanto, siempre se debe apuntar a lograr un tiempo de pausa de GC promedio bajo.

3. TIEMPO MÁXIMO DE PAUSA EN LA RECOGIDA DE BASURA

Algunos eventos de recolección de elementos no utilizados pueden demorar algunos milisegundos, mientras que algunos eventos de recolección de elementos no utilizados también pueden demorar entre segundos y minutos. Debe medir el tiempo máximo de pausa de recolección de basura para comprender el peor impacto posible para el cliente. Se necesita un ajuste adecuado (y, si es necesario, cambios en el código de la aplicación) para reducir el tiempo máximo de pausa de la recolección de elementos no utilizados.
**
4. TASA DE CREACIÓN DE OBJETOS**
La tasa de creación de objetos es la cantidad promedio de objetos creados por su aplicación. Tal vez en su confirmación de código anterior, la aplicación estaba creando 100 mb/seg. A partir de la confirmación de código reciente, la aplicación comenzó a crear 150 mb/seg. Esta tasa adicional de creación de objetos puede desencadenar mucha más actividad de GC, picos de CPU, posibles errores OutOfMemoryError, pérdidas de memoria cuando la aplicación se ejecuta durante un período más prolongado.

5. TAMAÑO MÁXIMO DEL MONTÓN

El tamaño máximo del almacenamiento dinámico es la cantidad máxima de memoria consumida por su aplicación. Si el tamaño máximo del almacenamiento dinámico supera un límite, debe investigarlo. Tal vez haya una posible fuga de memoria en la aplicación, el código recién introducido (o las terceras bibliotecas/marcos) está consumiendo mucha memoria, tal vez haya un uso legítimo, si es el caso, tendrá que cambiar sus argumentos JVM para asignar más memoria.

“El rendimiento de la recolección de basura, el tiempo promedio de pausa del GC, el tiempo máximo de pausa del GC, la tasa de creación de objetos, la micrométrica del tamaño máximo del almacenamiento dinámico solo se pueden obtener de los registros de recolección de basura. No se pueden utilizar otras herramientas para este propósito.
Como parte de su canalización de CI/CD, debe ejecutar un conjunto de pruebas de regresión o una prueba de rendimiento (ideal). Los registros de recolección de basura generados a partir de la prueba deben pasarse a API REST de GCeasy. Esta API analiza los registros de recolección de basura y responde con la micrometría mencionada anteriormente. Para saber dónde se envían estos micrométricos en la respuesta de la API y la expresión de la ruta JSON para ellos, a este artículo. Si se infringe algún valor, la compilación puede fallar. La API REST de GCeasy tiene inteligencia para detectar varios otros problemas de recolección de elementos no utilizados, como: fugas de memoria, tiempo de usuario > sys + tiempo real, tiempo de sys > tiempo de usuario, invocación de llamadas a la API System.gc(),… Se informará cualquier problema de GC detectado en el elemento ‘problema’ de la respuesta API. Es posible que desee realizar un seguimiento de este elemento también”.
**

  1. NÚMERO DE HILOS**
    El conteo de hilos puede ser otra métrica clave para monitorear. Si el recuento de subprocesos supera un límite, puede causar problemas de memoria y CPU. Demasiados subprocesos pueden causar ‘java.lang.OutOfMemoryError: incapaz de crear un nuevo subproceso nativo’ en el entorno de producción de ejecución prolongada.

7. ESTADOS DE ROSCAS

Los subprocesos de la aplicación pueden estar en diferentes estados de subprocesos. Para obtener información sobre varios estados de subprocesos, consulte este videoclip rapido. Demasiados subprocesos en estado EJECUTABLE pueden causar picos de CPU. Demasiados subprocesos en estado BLOQUEADO pueden hacer que la aplicación no responda. Si el número de subprocesos en un estado de subproceso en particular cruza cierto umbral, entonces puede considerar generar alertas/advertencias adecuadas en el informe de CI/CD.

8. GRUPOS DE ROSCAS

Un grupo de subprocesos representa una colección de subprocesos que realizan tareas similares. Podría haber un grupo de subprocesos de contenedor de servlet que procese todas las solicitudes HTTP entrantes. Podría haber un grupo de subprocesos JMS, que maneja toda la actividad de envío y recepción de JMS. También podría haber otros grupos de subprocesos sensibles en la aplicación. Es posible que desee realizar un seguimiento del tamaño de esos grupos de subprocesos sensibles. No desea que su tamaño caiga por debajo de un umbral ni supere un umbral. Una menor cantidad de subprocesos en un grupo de subprocesos puede detener las actividades. Una mayor cantidad de subprocesos puede generar problemas de memoria y CPU.

“El recuento de subprocesos, los estados de los subprocesos, la micrometría de los grupos de subprocesos se pueden obtener de los volcados de subprocesos. Como parte de su canalización de CI/CD, debe ejecutar un conjunto de pruebas de regresión o una prueba de rendimiento (ideal). 3 Los volcados de subprocesos en un intervalo de 10 segundos deben capturarse cuando se ejecutan las pruebas. Los volcados de subprocesos capturados deben pasarse a API REST de FastThread. Esta API analiza volcados de subprocesos y responde con las micrométricas mencionadas anteriormente.
Para saber dónde se envían estos micrométricos en la respuesta API y la expresión de ruta JSON para ellos, consulte a este artículo. Si se viola algún valor, entonces la construcción puede fallar”. La API REST de FastThread tiene inteligencia para detectar varios problemas de subprocesos, como: interbloqueos, subprocesos con picos de CPU, subprocesos de bloqueo prolongados, … Cualquier problema detectado se informará en el elemento ‘problema’ de la respuesta de la API. Es posible que desee realizar un seguimiento de este elemento también”.

9. MEMORIA DESPERDICIADA

En el mundo informático moderno, se desperdicia mucha memoria debido a prácticas de programación deficientes, como: creación de objetos duplicados, creación de cadenas duplicadas, implementaciones de colecciones ineficientes, definiciones de tipos de datos subóptimos, finalizaciones ineficientes, etc. Heap Hero API detecta una cantidad de memoria desperdiciada debido a todas estas prácticas de programación ineficientes. Esta puede ser una métrica clave para realizar un seguimiento. En caso de que la cantidad de memoria desperdiciada supere cierto porcentaje, la compilación de CI/CD puede fallar o se pueden generar advertencias.

10. CONTEO DE OBJETOS

También es posible que desee realizar un seguimiento del número total de objetos que están presentes en la memoria de la aplicación. El recuento de objetos puede aumentar debido a un código ineficiente, nueva introducción de bibliotecas de terceros, marcos. Demasiados objetos pueden causar OutOfMemoryError, pérdida de memoria, picos de CPU en producción.

11. CUENTA DE CLASES

También es posible que desee realizar un seguimiento del número total de clases que están presentes en la memoria de la aplicación. A veces, el recuento de clases puede aumentar debido a la introducción de bibliotecas o marcos de terceros. El pico en el conteo de clases puede causar problemas en el espacio Metaspace/PermGen de la memoria.

“El tamaño de la memoria desperdiciada, el recuento de objetos, la micrometría del recuento de clases se pueden obtener de los volcados de almacenamiento dinámico. Como parte de su canalización de CI/CD, debe ejecutar un conjunto de pruebas de regresión o una prueba de rendimiento (ideal). Los volcados de almacenamiento dinámico se deben capturar después de que se complete la ejecución de la prueba. Los volcados de almacenamiento dinámico capturados deben pasarse a RESTAPI de HeapHero. Esta API analiza volcados de almacenamiento dinámico y responde con esta micrométrica.
Para saber dónde se envían estos micrométricos en la respuesta de la API y la expresión de la ruta JSON para ellos, consulte este artículo. Si se viola algún valor, entonces la construcción puede fallar”. La API REST de HeapHero tiene la inteligencia para detectar varios problemas relacionados con la memoria, como: fugas de memoria, finalización de objetos,… Cualquier problema detectado se informará en el elemento ‘problema’ de la respuesta de la API. Es posible que desee realizar un seguimiento de este elemento también”.

Biografía del autor:

Ram Lakshmanán
Todos los días, millones y millones de personas en América del Norte (bancos, viajes y comercio) usan las aplicaciones que Ram Lakshmanan ha diseñado. Ram es un orador aclamado en las principales conferencias sobre temas de escalabilidad, disponibilidad y rendimiento. Recientemente, ha fundado una startup, que se especializa en solución de problemas de rendimiento.

Similar Posts

Leave a Reply

Your email address will not be published.