Priorización y control de procesos

Objetivo:

Comprender y gestionar la planificación de procesos en Linux, controlando la prioridad de ejecución mediante nice y renice, la gestión de tareas en primer y segundo plano (jobs, bg, fg) y la persistencia de procesos independientes de la sesión con nohup.

Escenario:

  • Herramientas: Terminal Linux, comandos nice, renice, ps, top, jobs, bg, fg, nohup, y señales de control (Ctrl+C, Ctrl+Z).
  • Conceptos analizados: Prioridades de CPU (valores nice de -20 a 19), procesos en primer plano (foreground) y segundo plano (background), tablas de trabajos del shell y persistencia ante el cierre de sesiones SSH/terminal.
  • Proceso clave: Lanzamiento de tareas pesadas simuladas, ajuste dinámico de prioridades para evitar la saturación del sistema, gestión de suspensión/reanudación de trabajos y ejecución desvinculada de procesos de larga duración.

Escenario Real: Gestión de tareas pesadas en servidores concurridos

Como administrador de sistemas, necesitas lanzar un script de compresión masiva o una tarea de respaldo pesada que consume una gran cantidad de ciclos de CPU en un servidor de producción. Si ejecutas el proceso con la prioridad por defecto, los servicios web críticos de la empresa sufrirán retrasos severos. Debes aprender a relegar prioridad a tareas secundarias y asegurar que los procesos críticos sigan ejecutándose aunque cierres la sesión de la terminal.

Por defecto, todos los procesos heredan una prioridad estándar de ejecución otorgada por el kernel. Sin embargo, en entornos multitarea avanzados, es imperativo saber cómo ceder recursos o arrebatárselos a procesos específicos, así como evitar que el cierre accidental de una ventana de terminal mate un proceso en plena ejecución.

NOTA: Para realizar esta práctica de forma segura, trabajaremos sobre tu propio entorno de prácticas local, utilizando bucles simulados de larga duración para observar el comportamiento del planificador de Linux sin poner en riesgo servicios reales.

Instrucciones:

Fase 1: Control de prioridades con nice (al iniciar procesos):

  • Lanzar un comando simulado de alta ocupación de CPU (un bucle infinito) asignándole una prioridad baja (nice positivo, por ejemplo, 10): nice -n 10 sleep 300 &
  • Comprobar la prioridad asignada (columna NI) y la prioridad real de ejecución (columna PR) mediante el comando: ps -l o ps -eo pid,ni,comm | grep sleep
  • Intentar arrancar un proceso con privilegios de mayor prioridad (nice -n -5) y comprobar la restricción de privilegios que solo permite a root incrementar prioridades.

Fase 2: Modificación dinámica de prioridades con renice (procesos en marcha):

  • Identificar el PID de cualquier proceso activo de prueba o lanzar uno nuevo en segundo plano: sleep 400 & (anotar su PID devuelto).
  • Modificar en caliente la prioridad de ese proceso ya en ejecución otorgándole un valor de nice de 15 para quitarle prioridad: sudo renice -n 15 -p [PID]
  • Verificar el cambio de prioridad ejecutando: ps -o pid,ni,cmd -p [PID]

Fase 3: Gestión de trabajos (Jobs), Foreground y Background:

  • Lanzar un proceso interactivo o simulado de larga duración en primer plano: sleep 500
  • Suspender el proceso en curso utilizando la combinación de teclas de interrupción del shell: Ctrl + Z
  • Listar los trabajos suspendidos y registrados en la tabla interna del shell: jobs
  • Reanudar la ejecución del proceso mandándolo a segundo plano: bg %1
  • Traer de vuelta el proceso al primer plano para interactuar con él: fg %1 (finalizarlo definitivamente pulsando Ctrl + C).

Fase 4: Persistencia de procesos desvinculados con nohup:

  • Lanzar un comando de larga duración asegurando que sobreviva al cierre de la sesión de terminal y redirigiendo la salida estándar: nohup sleep 600 > /dev/null 2>&1 &
  • Cerrar la sesión de terminal actual (o simular la desconexión) y volver a abrirla o comprobar los procesos activos del usuario: ps -u $USER | grep sleep
  • Verificar que el proceso sigue ejecutándose de manera independiente a pesar de haber cerrado el canal de la shell original.

Verificación:

  • Comprobar mediante el comando ps -eo pid,ni,cmd que los procesos creados reflejan correctamente los valores de NI modificados mediante nice o renice.
  • Verificar que la tabla de trabajos con jobs responde adecuadamente al suspender y reanudar tareas en segundo plano.

Posibles errores y resolución de problemas:

Si al intentar otorgar una prioridad superior (un valor de nice negativo, por ejemplo, -5) mediante el comando nice o renice el sistema devuelve un error de permisos denegados, se debe a una restricción de seguridad del kernel.

  • Solución: Los usuarios estándar solo tienen permiso para rebajar la prioridad de sus procesos (valores de nice positivos de 0 a 19). Para incrementar la prioridad (otorgando más recursos y valores negativos de -1 a -20), es obligatorio ejecutar la instrucción con privilegios de superusuario utilizando sudo.

Alternativa directa: Visualización interactiva de prioridades con top

Si prefieres auditar el consumo de CPU y los valores de prioridad (NI) de todos los procesos del sistema en tiempo real mediante una interfaz visual interactiva en lugar de usar comandos de consola estáticos, puedes invocar top y pulsar la letra r para cambiar la prioridad de un proceso introduciendo su PID al vuelo:

top
# Una vez dentro, pulsa 'r', introduce el PID y el nuevo valor de nice.

Preguntas de reflexión:

  1. ¿Qué rango de valores abarca la escala del parámetro nice en Linux, y qué relación inversa existe entre dicho valor numérico y la prioridad real de procesamiento asignada por el kernel?
  2. ¿Qué diferencia fundamental existe entre suspender un proceso usando Ctrl + Z frente a matarlo por completo utilizando Ctrl + C?
  3. ¿Por qué es necesario utilizar una utilidad como nohup (o herramientas de multiplexación como tmux o screen) al ejecutar tareas de larga duración en servidores remotos a los que accedemos por SSH?
  4. ¿Qué implicaciones tiene para el rendimiento general del sistema operativo ejecutar un proceso con un valor de nice igual a -20 frente a uno igual a 19?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué rango de valores abarca la escala del parámetro nice en Linux, y qué relación inversa existe entre dicho valor numérico y la prioridad real de procesamiento asignada por el kernel?

La escala de nice va desde -20 (máxima prioridad, acapara más ciclos de CPU) hasta 19 (mínima prioridad, cede recursos amablemente a los demás). La relación es inversamente proporcional: a mayor número de nice, menor prioridad de ejecución otorga el planificador del kernel al proceso.

2. ¿Qué diferencia fundamental existe entre suspender un proceso usando Ctrl + Z frente a matarlo por completo utilizando Ctrl + C?

La combinación Ctrl + C envía una señal de interrupción (SIGINT) que fuerza la finalización y cierre inmediato del proceso en ejecución. Por el contrario, Ctrl + Z envía una señal de pausa o suspensión (SIGTSTP), deteniendo temporalmente la ejecución del proceso y dejándolo registrado en la tabla de trabajos del shell para poder reanudarlo después en primer o segundo plano.

3. ¿Por qué es necesario utilizar una utilidad como nohup (o herramientas de multiplexación como tmux o screen) al ejecutar tareas de larga duración en servidores remotos a los que accedemos por SSH?

Porque al cerrar la sesión SSH o perderse la conexión, el kernel envía automáticamente una señal de colgar la línea (SIGHUP) a todos los procesos hijos asociados a esa pseudo-terminal, provocando su cierre abrupto. nohup ignora la señal SIGHUP permitiendo que el proceso continúe su ejecución de forma completamente independiente.

4. ¿Qué implicaciones tiene para el rendimiento general del sistema operativo ejecutar un proceso con un valor de nice igual a -20 frente a uno igual a 19?

Un proceso con nice -20 exigirá el máximo rendimiento al planificador de la CPU, pudiendo acaparar los recursos del procesador y provocar que otros servicios del sistema respondan con lentitud extrema. En contraste, un proceso con nice 19 se ejecutará exclusivamente cuando los recursos de la CPU estén completamente ociosos, garantizando que no afecte en absoluto al rendimiento de las aplicaciones críticas prioritarias.