Nice under Linux: calmar un proceso que consume muchos recursos sin detenerlo abruptamente.

Cuando un proceso de Linux comienza a consumir demasiada CPU, la primera reacción no siempre debe ser matarSi el servicio está funcionando correctamente, apagarlo abruptamente puede provocar que una tarea falle, que una copia de seguridad se corrompa o que un proceso en curso se interrumpa. En este caso, lindo Y renice te permite bajar su prioridad sin detenerlo.

Nota: Estos comandos no reducen la carga mágicamente. Modifican la prioridad de la CPU que le asigna el planificador de Linux. Esto es útil para darle un respiro al servidor, pero si una aplicación entra en un bucle o bloquea una base de datos, aún deberá revisar los registros y comprender la causa.

Comprenda el valor deseable antes de modificar un proceso.

Bajo Linux el valor lindo generalmente va desde menos veinte tiene diecinueveCuanto menor sea el valor, mayor será la prioridad del proceso. Cuanto mayor sea, más margen de maniobra habrá para otras tareas.

• menos veinte : prioridad muy alta, debe reservarse para casos controlados;
• cero : prioridad predeterminada de muchos procesos;
• diez O quince : menor prioridad, práctico para una tarea larga y no urgente;
• diecinueve : prioridad muy baja.

Un usuario típico generalmente puede reducir la prioridad de sus propios procesos. Para aumentar la prioridad de un proceso se requieren privilegios de administrador. Esto es intencional: establecer una prioridad demasiado alta en un servidor compartido puede afectar el funcionamiento del resto del sistema.

Ejecutar un comando con menor prioridad

el orden lindo Se utiliza al iniciar un programa. Ejemplo sencillo:

comando nice -n 10

En caso de compresión intensa, esto puede resultar en:

nice -n 10 tar -czf backup.tar.gz /srv/data

La tarea se ejecuta constantemente, pero evita interferir con otros procesos de forma excesiva. La utilizo principalmente para el procesamiento en segundo plano: compresión, conversión, escaneo, scripts personalizados u operaciones largas que no necesitan finalizar en un minuto.

Si ejecutas el comando desde un script cron o una terminal SSH, sigue vigilando la carga. Una prioridad menor no sustituye una monitorización mínima.

Consulta la prioridad actual con ps, top o htop.

Antes de cambiar nada, identifique el proceso involucrado. Una salida PD. A menudo, basta con ir a por todas:

ps -eo pid,ni,pri,pcpu,pmem,comm --sort=-pcpu | head

la columna NI muestra el valor «nice». La columna PRI otorga una prioridad calculada por el kernel. Para una lectura rápida en vivo, también puede abrir:

arriba

O usar htop para leer la carga del servidorEn htop, ordenar por CPU y luego verificar el PID ya evita que el usuario tome muchas decisiones equivocadas.

Modificar un proceso ya iniciado con renice

Si el proceso ya está en ejecución, lindo ya no es suficiente. Debemos usar renicePrimero, recupera el PID y luego reduce la prioridad:

Renice +10 -p 1234

Aquí, mil doscientos treinta y cuatro debe reemplazarse con el PID real. En un proceso que pertenece a otro usuario, o si desea aumentar su prioridad, pase por sudo :

sudo renice -5 -p 1234

Desaconsejo establecer valores negativos sin una razón específica. En un servidor de producción, esta rara vez es la mejor primera respuesta. Reducir la prioridad de un proceso que consume muchos recursos suele ser más beneficioso que otorgar un acceso excesivo a la CPU a un servicio mal diagnosticado.

Verifique que el cambio se haya aplicado.

Después de un renice, vuelve a leer el valor NI :

ps -o pid,ni,pri,pcpu,pmem,comm -p 1234

También puedes consultar la carga total:

tiempo de actividad

Si el servidor sigue lento, no concluya demasiado rápido que renice no funciona. El cuello de botella podría ser el disco, la memoria, un bloqueo de aplicación o un servicio que se reinicia en un bucle. En este caso, revise los registros con diarioctl y registros de aplicaciones con cola.

Cuando ser amable no es suficiente

lindo Y renice Estas medidas afectan la prioridad de la CPU. No limitan la memoria, no corrigen consultas SQL erráticas ni reemplazan un límite de recursos real. Si necesita limitar correctamente un servicio, consulte systemd, cgroups o la configuración de la aplicación.

Si el proceso está claramente bloqueado o es peligroso, puede que sea necesario detenerlo. En este caso, utilice el método adecuado: identifique el servicio, lea los registros, intente un apagado normal y solo entonces utilice [el método apropiado]. matar sin detener el mal proceso.

Las páginas del manual de lindo, renice Y PD. En ellas se detallan las opciones disponibles. En la práctica, recuerde esta regla por encima de todo: reduzca la prioridad de una tarea de larga duración si está ralentizando el servidor, pero no la utilice para enmascarar un problema real de carga.

sudo apt update && sudo apt upgrade