Un servidor presenta un consumo anómalo de CPU y memoria

Objetivo:

Diagnosticar y resolver una incidencia crítica de rendimiento en un servidor que experimenta un consumo anómalo y sostenido de CPU y memoria, aprendiendo a identificar procesos consumidores, auditar registros del sistema, aislar servicios desbocados y aplicar medidas correctoras efectivas.

Escenario:

  • Herramientas: Terminal Linux, comandos top, htop, ps, journalctl, y gestión de prioridades con renice / kill.
  • Conceptos analizados: Fugas de memoria (memory leaks), procesos zombis o huérfanos, bucles de ejecución en servicios web o bases de datos, y prioridades de planificación del kernel (valores nice).
  • Proceso clave: Detección del cuello de botella global, identificación del PID (Process ID) responsable, inspección de logs asociados, parada o limitación del recurso desbocado y verificación de la estabilización del servidor.

Escenario Real: Servidor colapsado por un proceso desbocado

Un servidor crítico de aplicaciones muestra una carga del procesador al 100% y la memoria RAM completamente agotada, provocando que el acceso remoto por SSH sea extremadamente lento o inestable. Como administrador de sistemas, debes realizar una intervención de urgencia para identificar qué proceso o demonio está consumiendo los recursos de forma anómala, auditar los registros para descubrir la causa y aplicar las medidas correctoras para recuperar la normalidad.

Por defecto, los servidores pueden sufrir caídas de rendimiento debido a procesos mal programados, ataques de denegación de servicio (DoS) locales o bucles infinitos en aplicaciones web. Saber aislar el origen del consumo excesivo es una habilidad fundamental de administración.

NOTA: Para realizar esta práctica de diagnóstico con seguridad, evita eliminar procesos críticos del núcleo del sistema (como systemd o kswapd) cuyo cierre forzoso provocaría un bloqueo total del servidor.

Instrucciones:

Fase 1: Detección global de la carga y uso de recursos:

  • Comprobar la carga media del sistema (Load Average) y el consumo porcentual general de CPU y memoria en tiempo real: top (o pulsar htop para una interfaz visual más avanzada).
  • Ordenar los procesos activos de manera interactiva pulsando la tecla P (por uso de CPU) o M (por uso de memoria) para identificar los candidatos sospechosos.

Fase 2: Identificación precisa del proceso y sus metadatos:

  • Listar los procesos del sistema filtrando aquellos que devoren más recursos mediante el comando ps con formato personalizado: 
    ps aux --sort=-%cpu,%mem | head -n 10
  • Anotar el identificador del proceso (PID), el usuario propietario, el tiempo de ejecución y la ruta del binario en ejecución.

Fase 3: Auditoría de registros (logs) asociados al servicio:

  • Inspeccionar el registro del sistema o los logs específicos del demonio sospechoso para descubrir errores recurrentes, excepciones o avisos de falta de memoria (Out Of Memory): sudo journalctl -u [nombre_servicio] -n 50 --no-pager
  • Comprobar si el kernel ha lanzado avisos de OOM killer en el búfer general: dmesg -T | grep -i oom

Fase 4: Aplicación de medidas correctoras y mitigación:

  • Si el proceso responde, intentar una parada controlada mediante systemctl o enviar una señal de terminación limpia al PID: sudo kill -15 [PID]
  • Si el proceso está congelado y continúa devorando los recursos, forzar su cierre inmediato: sudo kill -9 [PID]
  • Si se trata de un servicio legítimo sobrecargado, ajustar su prioridad de ejecución en el procesador utilizando un valor nice positivo o reiniciar el demonio correspondiente.

Verificación:

  • Comprobar mediante top o htop que la carga media del procesador ha descendido a valores nominales y que el consumo de memoria se ha estabilizado.
  • Verificar que los servicios principales de la aplicación operan con normalidad tras la eliminación del proceso anómalo.

Posibles errores y resolución de problemas:

Si al intentar finalizar un proceso desbocado mediante el comando kill el sistema devuelve un error indicando que Operation not permitted, se debe a que estás ejecutando el comando con una cuenta de usuario sin privilegios suficientes para gestionar procesos de otros usuarios o del sistema.

  • Solución: Eleva tus privilegios ejecutando la orden anteponiendo el comando de administración, por ejemplo: sudo kill -9 [PID].

Alternativa directa: Visualización rápida de los procesos más pesados

Si necesitas obtener una lista instantánea y limpia de los procesos que más memoria RAM están absorbiendo sin interactuar con herramientas de pantalla completa como htop, puedes ejecutar el comando optimizado:

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -n 6

Preguntas de reflexión:

  1. ¿Qué diferencia técnica existe entre enviar una señal de terminación suave (SIGTERM o kill -15) frente a una señal de cierre forzoso (SIGKILL o kill -9) a un proceso desbocado?
  2. ¿Cómo influye una fuga de memoria (memory leak) en el rendimiento a largo plazo de un servidor hasta obligar al kernel a actuar mediante el mecanismo OOM Killer?
  3. ¿Qué significado técnico aportan los tres valores que componen la carga media del sistema (Load Average) en intervalos de 1, 5 y 15 minutos?
  4. ¿Qué utilidad aporta modificar la prioridad de planificación (valores nice) de un proceso pesado en un servidor multitarea saturado?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué diferencia técnica existe entre enviar una señal de terminación suave (SIGTERM o kill -15) frente a una señal de cierre forzoso (SIGKILL o kill -9) a un proceso desbocado?

La señal SIGTERM (15) solicita amablemente al proceso que finalice su ejecución, dándole la oportunidad de liberar recursos abiertos, cerrar conexiones de red y guardar ficheros temporales de forma limpia. Por el contrario, la señal SIGKILL (9) es interceptada directamente por el kernel del sistema operativo, el cual detiene y elimina el proceso de inmediato sin permitirle realizar ninguna tarea de limpieza previa.

2. ¿Cómo influye una fuga de memoria (memory leak) en el rendimiento a largo plazo de un servidor hasta obligar al kernel a actuar mediante el mecanismo OOM Killer?

Una fuga de memoria ocurre cuando una aplicación solicita bloques de RAM al sistema operativo pero olvida liberarlos al terminar sus tareas, haciendo que su consumo crezca de manera constante con el tiempo. Cuando la memoria física y el espacio de intercambio (swap) se agotan por completo, el kernel activa el mecanismo OOM (Out Of Memory) Killer para asesinar de forma automática al proceso que más recursos consume con el fin de evitar un bloqueo general del servidor.

3. ¿Qué significado técnico aportan los tres valores que componen la carga media del sistema (Load Average) en intervalos de 1, 5 y 15 minutos?

Representan el número medio de procesos que se encuentran en estado ejecutable (utilizando la CPU) o en espera ininterrumpida de recursos (como operaciones de E/S de disco) durante los últimos 1, 5 y 15 minutos. Comparar estos tres valores permite discernir si un pico de carga es un evento puntual y transitorio o un problema estructural sostenido en el tiempo.

4. ¿Qué utilidad aporta modificar la prioridad de planificación (valores nice) de un proceso pesado en un servidor multitarea saturado?

Los valores nice oscilan generalmente entre -20 (máxima prioridad) y 19 (mínima prioridad). Asignar un valor positivo alto a un proceso secundario pesado pero no urgente permite degradar su prioridad en la cola del procesador, cediendo de manera justa los ciclos de cálculo de la CPU a los servicios críticos de la organización.