Deadlock

APM – Cómo diagnosticar problemas repentinos

En este artículo indicamos cómo podemos identificar los distintos tipos de problemas repentinos y cómo debemos priorizar para solucionarlos.

Definición de problema repentino

Un problema repentino es:

  • Instantáneo, no es lineal ni progresivo
  • Ocurre sin aviso, funciona bien un minuto y deja de hacerlo al siguiente
  • Es recurrente, pero en horarios diferentes

El servidor de aplicaciones puede llegara colgarse, comenzar a generar errores o actuar caóticamente y el problema normalmente afecta a todas las funcionalidades

Tipos de Problemas Repentinos

  • Interbloqueo activo
  • Reintentos sin fin
  • Un cerdo en la pitón
  • Un Backend repentinamente lento
  • Punto muerto

Interbloqueo activo

El interbloqueo activo es un proceso en ejecución que consume excesivos recursos. Un bucle infinito en el código fuente, un bucle que no especifica cuándo se termina la repetición o un bucle que no puede terminar de ejecutarse porque la expresión condicional es siempre verdad.

Las métricas que definen este tipo de error son las siguientes:

  • El tiempo de respuesta medio crece ya que la CPU está ocupada en el bucle hasta poder llegar a infinito
  • El uso de CPU crece tendiendo a un uso del 100%, ya que el sistema está ejecutando el bucle de forma continua
  • Como el hilo está ejecutando el proceso, podemos identificar que los hilos con ese problema no se liberen y estén ejecutándose al 100% de CPU

Este problema es un problema de código y hay que reenviárselo al programador o al arquitecto

Reintentos sin fin

Pueden estar causados por componentes que hagan llamadas continuas a sistemas no disponibles, es uno de los problemas más comunes de que el sistema se cuelgue o deje de responder.

Suele ocurrir cuando el componente no puede diferenciar entre una respuesta exitosa o un fallo y para solucionarla requiere una monitorización del back-end

Las métricas que definen este problema son las siguientes:

  • El tiempo de respuesta para el método que llama el sistema se incrementa
  • El número de threads disponibles llega a cero si el problema es muy grave
  • En un dump de threads, se ve que los threads están detenidos en el método que causa el problema
  • El uso de CPU tiende a cero, que que la máquina no puede realizar trabajo al estar a la espera de respuesta

El problema hay que redirigirlo al programador y/o arquitecto por si es un problema de desarrollo de no identificar si la respuesta no ha llegado de forma correca o no, y también hay que redirigirla al administrador del sistema backend para que lo compruebe

El cerdo en la pitón

Este problema viene como el nombre dice, por intentar hacer pasar algo grande por un canal pequeño. Por ejemplo, consumir toda la memoria disponible por conjuntos de datos enormes, normalmente se recibe un error de Out of Memory.

Las métricas que definen este problema son las siguientes:

  • Mayor tiempo de respuesta de la media en el método que llama al objeto
  • La memoria utilizada tiende a ser igual a la memoria disponible
  • El número de respuestas por intervalo disminuye
  • Y en un dump de memoria, se vería el uso de memoria de ese objeto.

Para solucionar este problema que siempre es de programación, hay que enviárselo al programador o al arquitecto.

Backend repentinamente lento

Hay múltiples causas para un bajo rendimiento de la base de datos, como:

  • Saturación de la red
  • Bloqueo por otro usuario
  • Recursos de base de datos inadecuada
  • Boqueo por otro proceso
  • Mal diseño de la Base de Datos o del Esquema de Datos

Hay que mantener actualizadas las estadísticas y monitorizar cada instalación de base de datos

Las métricas que identifican este problema son las siguientes:

  • Tiempos de respuesta elevados en las peticiones a la base de datos
  • El número de hilos decrece
  • En un dump de threads se identifican los métodos que llaman a las consultas que terminan generando los problemas

Este tipo de problemas hay que redirecccionarlo al responsable del sistema backend

Punto Muerto

El punto muerto ocurre cuando dos procesos bloqueados se esperan el uno al otro para levantar el bloqueo. El punto muerto es un punto único de fallo, bloqueando otras peticiones

Deadlock

Las métricas que identifican este problema son las siguientes:

  • En un dump de threads, se ve que el número de threads bloqueados se va incrementando paulativamente y siempre teniendo como origen la primera de las funcionaes.
  • Las respuestas por intervalo se decrementan
  • El número de threads, se decrementa hasta llegar a cero
  • El uso de CPU va decayendo, ya que todos los procesos están esperando a que uno se libere y por tanto no se puede ejecutar nada.

Este es siempre un problema de código y por tanto hay que enviarlo al programador o al arquitecto.

Si necesita más información sobre APM, o configuración de monitorización de sus aplicaciones no dude en contactar con nosotros en nuestro correo.

Tenemos más de 10 años de experiencia en monitoreo de aplicaciones en implantaciones de más de 10.000 servidores de aplicaciones en diferentes países.

Compartir el artículo:
Scroll to top