Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

236
Vistas
La ejecución de la prueba de rendimiento de 24 horas dejó de ejecutarse abruptamente en jmeter pod en AKS

Estoy ejecutando una prueba de carga de 24 horas usando Jmeter en el servicio Azure Kubernetes. Estoy usando el temporizador de modelado de rendimiento en mi archivo jmx. No se agrega ningún oyente como parte del archivo jmx. Mi prueba se detuvo abruptamente después de 6 o 7 horas.

El archivo jmeter-server.log en Jmeter slave pod está dando una advertencia --> WARN kajtVariableThroughputTimer: No quedan subprocesos libres en el grupo de trabajadores .

A continuación se muestra una instantánea del archivo jmeter-server.log. ingrese la descripción de la imagen aquí

Usando la versión de Jmeter - 5.2.1 y la versión de Kubernetes - 1.19.6

Lo comprobé, los pods de Jmeter para maestros y esclavos se ejecutan continuamente (no se produjo ningún reinicio) en AKS. Proporcioné 2 GB de memoria al pod esclavo de Jmeter, pero la prueba de carga se detuvo abruptamente. Estoy usando el espacio de trabajo de análisis de registros para iniciar sesión. La tabla ContainerLog comprobada no recibe el error.

Instantánea del archivo JMX. Usando los siguientes elementos -> Grupo de subprocesos, Controlador de rendimiento, Muestreador de solicitud Http y Temporizador de modelado de rendimiento ingrese la descripción de la imagen aquí

Por favor sugiera lo mismo.

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

Parece que la configuración de la función de retroalimentación de programación es incorrecta en su último parámetro

ingrese la descripción de la imagen aquí

La advertencia significa que el temporizador de modelado de rendimiento intenta aumentar la cantidad de subprocesos para alcanzar/mantener la simultaneidad deseada, pero no tiene suficientes subprocesos para hacerlo.

Entonces, aumente esta proporción de Spare threads ration para que esté más cerca de 1 si está utilizando un valor flotante para el porcentaje o incremente el valor absoluto para que coincida con la cantidad de subprocesos.

Cita de la documentación:

Llamada de función de ejemplo: ${__tstFeedback(tst-name,1,100,10)} , donde "tst-name" es el nombre del temporizador de modelado de rendimiento para integrar, 1 y 100 son subprocesos iniciales y subprocesos máximos permitidos, 10 es cuántos sobran subprocesos para mantener en el grupo de subprocesos. Si el parámetro de subprocesos de repuesto es un valor flotante <1, entonces se interpreta como una proporción relativa a la estimación actual de subprocesos necesarios. Si está por encima de 1, los subprocesos de repuesto se interpretan como un recuento absoluto.

Más información: Uso del complemento de temporizador de modelado de rendimiento de JMeter

Sin embargo, no explica la terminación prematura de la prueba, así que asegúrese de que no haya errores en los registros de jmeter/k8s, una de las posibles razones es que OOMKiller está terminando el proceso de JMeter.

over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda