103.6 Lección 1
Certificación: |
LPIC-1 |
---|---|
Versión: |
5.0 |
Tema: |
103 Comandos GNU y Unix |
Objetivo: |
103.6 Modificar las prioridades de ejecución de procesos |
Lección: |
1 de 1 |
Introducción
Los sistemas operativos capaces de ejecutar más de un proceso al mismo tiempo se denominan sistemas multitarea o multiprocesamiento. Si bien la verdadera simultaneidad solo ocurre cuando hay más de una unidad de procesamiento disponible, incluso los sistemas de un solo procesador pueden imitar la simultaneidad al cambiar entre procesos muy rápidamente. Esta técnica también se emplea en sistemas con muchas CPU equivalentes, o sistemas multiprocesador simétrico (SMP), dado que el número de procesos concurrentes potenciales supera con creces el número de unidades procesadoras disponibles.
De hecho, solo un proceso a la vez puede controlar la CPU. Sin embargo, la mayoría de las actividades del proceso son llamadas al sistema, es decir, el proceso en ejecución transfiere el control de la CPU al proceso de un sistema operativo para que realice la operación solicitada. Las llamadas al sistema están a cargo de toda la comunicación entre dispositivos, como asignaciones de memoria, lectura y escritura en sistemas de archivos, impresión de texto en la pantalla, interacción del usuario, transferencias de red, etc. La transferencia del control de la CPU durante una llamada al sistema permite, que el sistema operativo decida si devolver el control de la CPU al proceso anterior o pasarlo a otro proceso. Como las CPU modernas pueden ejecutar instrucciones mucho más rápido de lo que la mayoría del hardware externo puede comunicarse entre sí, un nuevo proceso de control puede hacer mucho trabajo de la CPU mientras que las respuestas de hardware solicitadas anteriormente aún no están disponibles. Para garantizar el máximo aprovechamiento de la CPU, los sistemas operativos de multiprocesamiento mantienen una cola dinámica de procesos activos en espera de un intervalo de tiempo de la CPU.
Aunque permiten mejorar significativamente la utilización del tiempo de la CPU, depender únicamente de las llamadas al sistema para cambiar entre procesos no es suficiente para lograr un rendimiento multitarea satisfactorio. Un proceso que no realiza llamadas al sistema podría controlar la CPU de forma indefinida. Esta es la razón por la que los sistemas operativos modernos también son preferentes, es decir, un proceso en ejecución se puede volver a poner en la cola para que un proceso más importante pueda controlar la CPU, incluso si el proceso en ejecución no ha realizado una llamada al sistema.
El planificador de Linux
Linux, como sistema operativo de multiprocesamiento preventivo, implementa un planificador que organiza la cola de procesos. Más precisamente, el planificador también decide qué subproceso en cola se ejecutará (un proceso puede ramificar muchos subprocesos independientes), pero proceso y subproceso son términos intercambiables en este contexto. Cada proceso tiene dos predicados que intervienen en su programación: la política de programación y la prioridad de programación.
Hay dos tipos principales de políticas de programación: políticas en tiempo real y políticas normales. Los procesos bajo una política de tiempo real se programan directamente por sus valores de prioridad. Si un proceso más importante está listo para ejecutarse, se sustituye por un proceso en ejecución menos importante y el proceso de mayor prioridad toma el control de la CPU. Un proceso de menor prioridad obtendrá el control de la CPU solo si los procesos de mayor prioridad están inactivos o esperando la respuesta del hardware.
Cualquier proceso en tiempo real tiene mayor prioridad que un proceso normal. Como sistema operativo de propósito general, Linux ejecuta solo algunos procesos en tiempo real. La mayoría de los procesos, incluidos los programas de usuario y del sistema, se ejecutan según las políticas de programación normales. Los procesos normales suelen tener el mismo valor de prioridad, pero las políticas normales pueden definir reglas de prioridad de ejecución utilizando otro predicado de proceso: el valor nice. Para evitar confusiones con las prioridades dinámicas derivadas de valores agradables, las prioridades de programación generalmente se denominan prioridades de programación estáticas.
El planificador de Linux se puede configurar de muchas formas diferentes y existen formas aún más complejas de establecer prioridades, pero estos conceptos generales siempre se aplican. Al inspeccionar y ajustar la programación del proceso, es importante tener en cuenta que solo se verán afectados los procesos bajo la política de programación normal.
Prioridades de lectura
Linux reserva prioridades estáticas que van de 0 a 99 para procesos en tiempo real y los procesos normales se asignan a prioridades estáticas que van de 100 a 139, lo que significa que hay 39 niveles de prioridad diferentes para procesos normales. Los valores más bajos significan una prioridad más alta. La prioridad estática de un proceso activo se puede encontrar en el archivo sched
, ubicado en su directorio respectivo dentro del sistema de archivos /proc
:
$ grep ^prio /proc/1/sched prio : 120
Como se muestra en el ejemplo, la línea que comienza con prio
da el valor de prioridad del proceso (el proceso PID 1 es el proceso init o systemd, el primer proceso que el kernel inicia durante la inicialización del sistema). La prioridad estándar para los procesos normales es 120, de modo que se puede reducir a 100 o aumentar a 139. Las prioridades de todos los procesos en ejecución se pueden verificar con el comando ps -Al
o ps -el
:
$ ps -el F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 4 S 0 1 0 0 80 0 - 9292 - ? 00:00:00 systemd 4 S 0 19 1 0 80 0 - 8817 - ? 00:00:00 systemd-journal 4 S 104 61 1 0 80 0 - 64097 - ? 00:00:00 rsyslogd 4 S 0 63 1 0 80 0 - 7244 - ? 00:00:00 cron 1 S 0 126 1 0 80 0 - 4031 - ? 00:00:00 dhclient 4 S 0 154 1 0 80 0 - 3937 - pts/0 00:00:00 agetty 4 S 0 155 1 0 80 0 - 3937 - pts/1 00:00:00 agetty 4 S 0 156 1 0 80 0 - 3937 - pts/2 00:00:00 agetty 4 S 0 157 1 0 80 0 - 3937 - pts/3 00:00:00 agetty 4 S 0 158 1 0 80 0 - 3937 - console 00:00:00 agetty 4 S 0 160 1 0 80 0 - 16377 - ? 00:00:00 sshd 4 S 0 280 0 0 80 0 - 5301 - ? 00:00:00 bash 0 R 0 392 280 0 80 0 - 7221 - ? 00:00:00 ps
La columna PRI
indica la prioridad estática asignada por el kernel. Sin embargo, tenga en cuenta que el valor de prioridad mostrado por ps
difiere del obtenido en el ejemplo anterior. Debido a razones históricas, las prioridades mostradas por ps
varían de -40 a 99 por defecto, por lo que la prioridad real se obtiene agregando 40 (en particular, 80 + 40 = 120).
También es posible monitorear continuamente los procesos que actualmente administra el kernel de Linux con el programa top
. Al igual que con ps
, top
también muestra el valor de prioridad de forma diferente. Para que sea más fácil identificar los procesos en tiempo real, top
resta 100 del valor de prioridad, por lo que todas las prioridades en tiempo real son negativas, con un número negativo o rt identificándolas. Por lo tanto, las prioridades normales mostradas por top
van de 0 a 39.
Note
|
Para obtener más detalles del comando $ ps -e -o user,uid,comm,tty,pid,ppid,pri,pmem,pcpu --sort=-pcpu | head |
Niceness de Procesos
Todo proceso normal comienza con un valor nice predeterminado de 0 (prioridad 120). El nombre nice proviene de la idea de que los procesos “más agradables” permiten que otros procesos se ejecuten antes que ellos en una cola de ejecución particular. Los números nice van desde -20 (menos agradables, alta prioridad) a 19 (más agradables, baja prioridad). Linux también permite la capacidad de asignar diferentes valores nice a subprocesos dentro del mismo proceso. La columna NI
en la salida de ps
indica el número nice.
Solo el usuario root puede disminuir el valor nice de un proceso por debajo de cero. Es posible iniciar un proceso con una prioridad no estándar con el comando nice
. Por defecto, nice
cambia el valor a 10, pero se puede especificar con la opción -n
:
$ nice -n 15 tar czf home_backup.tar.gz /home
En este ejemplo, el comando tar
se ejecuta con un valor nice de 15. El comando renice
puede usarse para cambiar la prioridad de un proceso en ejecución. La opción -p
indica el número PID del proceso objetivo. Por ejemplo:
# renice -10 -p 2164 2164 (process ID) old priority 0, new priority -10
Las opciones -g
y -u
se utilizan para modificar todos los procesos de un grupo o usuario específico, respectivamente. Con renice +5 -g users
, el valor nice de los procesos propiedad de los usuarios del grupo users se elevará en cinco.
Además de renice
, la prioridad de los procesos se puede modificar con otros programas, como el programa top
. En la pantalla principal superior, el valor nice de un proceso se puede modificar presionando r
y luego el número PID del proceso:
top - 11:55:21 up 23:38, 1 user, load average: 0,10, 0,04, 0,05 Tasks: 20 total, 1 running, 19 sleeping, 0 stopped, 0 zombie %Cpu(s): 0,5 us, 0,3 sy, 0,0 ni, 99,0 id, 0,0 wa, 0,2 hi, 0,0 si, 0,0 st KiB Mem : 4035808 total, 774700 free, 1612600 used, 1648508 buff/cache KiB Swap: 7999828 total, 7738780 free, 261048 used. 2006688 avail Mem PID to renice [default pid = 1] PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 74232 7904 6416 S 0,000 0,196 0:00.12 systemd 15 root 20 0 67436 6144 5568 S 0,000 0,152 0:00.03 systemd-journal 21 root 20 0 61552 5628 5000 S 0,000 0,139 0:00.01 systemd-logind 22 message+ 20 0 43540 4072 3620 S 0,000 0,101 0:00.03 dbus-daemon 23 root 20 0 45652 6204 4992 S 0,000 0,154 0:00.06 wickedd-dhcp4 24 root 20 0 45648 6276 5068 S 0,000 0,156 0:00.06 wickedd-auto4 25 root 20 0 45648 6272 5060 S 0,000 0,155 0:00.06 wickedd-dhcp6
Aparece el mensaje PID to renice [default pid = 1]
con el primer proceso listado seleccionado por defecto. Para cambiar la prioridad de otro proceso, escriba su PID y presione Enter. Luego, aparecerá el mensaje Renice PID 1 to value
(con el número PID solicitado) y se puede asignar un nuevo valor nice.
Ejercicios Guiados
-
En un sistema multitarea preventivo, ¿qué sucede cuando un proceso de menor prioridad ocupa el procesador y un proceso de mayor prioridad se pone en cola para su ejecución?
-
Considere la siguiente pantalla
top
:top - 08:43:14 up 23 days, 12:29, 5 users, load average: 0,13, 0,18, 0,21 Tasks: 240 total, 2 running, 238 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,4 us, 0,4 sy, 0,0 ni, 98,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 7726,4 total, 590,9 free, 1600,8 used, 5534,7 buff/cache MiB Swap: 30517,0 total, 30462,5 free, 54,5 used. 5769,4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 171420 10668 7612 S 0,0 0,1 9:59.15 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:02.76 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_gp 8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0,0 0,0 0:49.06 ksoftirqd/0 10 root 20 0 0 0 0 I 0,0 0,0 18:24.20 rcu_sched 11 root 20 0 0 0 0 I 0,0 0,0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0,0 0,0 0:08.17 migration/0 14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1 16 root rt 0 0 0 0 S 0,0 0,0 0:11.79 migration/1 17 root 20 0 0 0 0 S 0,0 0,0 0:26.01 ksoftirqd/1
¿Qué PID tienen prioridades en tiempo real?
-
Considere la siguiente lista
ps -el
:F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 4 S 0 1 0 0 80 0 - 42855 - ? 00:09:59 systemd 1 S 0 2 0 0 80 0 - 0 - ? 00:00:02 kthreadd 1 I 0 3 2 0 60 -20 - 0 - ? 00:00:00 rcu_gp 1 S 0 9 2 0 80 0 - 0 - ? 00:00:49 ksoftirqd/0 1 I 0 10 2 0 80 0 - 0 - ? 00:18:26 rcu_sched 1 I 0 11 2 0 80 0 - 0 - ? 00:00:00 rcu_bh 1 S 0 12 2 0 -40 - - 0 - ? 00:00:08 migration/0 1 S 0 14 2 0 80 0 - 0 - ? 00:00:00 cpuhp/0 5 S 0 15 2 0 80 0 - 0 - ? 00:00:00 cpuhp/1
¿Qué PID tiene mayor prioridad?
-
Después de intentar modificar un proceso con
renice
, ocurre el siguiente error:$ renice -10 21704 renice: failed to set priority for 21704 (process ID): Permission denied
¿Cuál es la causa probable del error?
Ejercicios Exploratorios
-
Por lo general, es necesario cambiar las prioridades del proceso cuando un proceso ocupa demasiado tiempo de CPU. Usando
ps
con opciones estándar para imprimir todos los procesos del sistema en formato largo, ¿qué valor de--sort
ordenará los procesos por uso de CPU, aumentando el orden? -
El comando
schedtool
puede establecer todos los parámetros de programación de la CPU de los que Linux es capaz o mostrar información para procesos dados. ¿Cómo se puede utilizar para mostrar los parámetros de programación del proceso1750
? Además, ¿cómo se puede usarschedtool
para cambiar el proceso 1750 a tiempo real con prioridad -90 (como se muestra entop
)?
Resumen
Esta lección cubre cómo Linux comparte el tiempo de CPU entre sus procesos administrados. Para garantizar el mejor rendimiento, los procesos más críticos deben superar a los procesos menos críticos. La lección pasa por los siguientes pasos:
-
Conceptos básicos sobre sistemas multiprocesamiento.
-
¿Qué es un planificador de procesos y cómo lo implementa Linux?
-
¿Cuáles son las prioridades de Linux, números nice y su propósito?
-
Cómo leer e interpretar las prioridades de los procesos en Linux.
-
Cómo cambiar la prioridad de un proceso, antes y durante su ejecución.
Respuestas a los ejercicios guiados
-
En un sistema multitarea preventivo, ¿qué sucede cuando un proceso de menor prioridad ocupa el procesador y un proceso de mayor prioridad se pone en cola para su ejecución?
El proceso de menor prioridad se detiene y en su lugar se ejecuta el proceso de mayor prioridad.
-
Considere la siguiente pantalla
top
:top - 08:43:14 up 23 days, 12:29, 5 users, load average: 0,13, 0,18, 0,21 Tasks: 240 total, 2 running, 238 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,4 us, 0,4 sy, 0,0 ni, 98,1 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 7726,4 total, 590,9 free, 1600,8 used, 5534,7 buff/cache MiB Swap: 30517,0 total, 30462,5 free, 54,5 used. 5769,4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 0 171420 10668 7612 S 0,0 0,1 9:59.15 systemd 2 root 20 0 0 0 0 S 0,0 0,0 0:02.76 kthreadd 3 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 rcu_par_gp 8 root 0 -20 0 0 0 I 0,0 0,0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0,0 0,0 0:49.06 ksoftirqd/0 10 root 20 0 0 0 0 I 0,0 0,0 18:24.20 rcu_sched 11 root 20 0 0 0 0 I 0,0 0,0 0:00.00 rcu_bh 12 root rt 0 0 0 0 S 0,0 0,0 0:08.17 migration/0 14 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/0 15 root 20 0 0 0 0 S 0,0 0,0 0:00.00 cpuhp/1 16 root rt 0 0 0 0 S 0,0 0,0 0:11.79 migration/1 17 root 20 0 0 0 0 S 0,0 0,0 0:26.01 ksoftirqd/1
¿Qué PIDs tienen prioridades en tiempo real?
PIDs 12 y 16.
-
Considere la siguiente lista
ps -el
:F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD 4 S 0 1 0 0 80 0 - 42855 - ? 00:09:59 systemd 1 S 0 2 0 0 80 0 - 0 - ? 00:00:02 kthreadd 1 I 0 3 2 0 60 -20 - 0 - ? 00:00:00 rcu_gp 1 S 0 9 2 0 80 0 - 0 - ? 00:00:49 ksoftirqd/0 1 I 0 10 2 0 80 0 - 0 - ? 00:18:26 rcu_sched 1 I 0 11 2 0 80 0 - 0 - ? 00:00:00 rcu_bh 1 S 0 12 2 0 -40 - - 0 - ? 00:00:08 migration/0 1 S 0 14 2 0 80 0 - 0 - ? 00:00:00 cpuhp/0 5 S 0 15 2 0 80 0 - 0 - ? 00:00:00 cpuhp/1
¿Qué PID tiene mayor prioridad?
PID 12.
-
Después de intentar modificar un proceso con
renice
, ocurre el siguiente error:$ renice -10 21704 renice: failed to set priority for 21704 (process ID): Permission denied
¿Cuál es la causa probable del error?
Solo el usuario root puede disminuir los números nice por debajo de cero.
Respuestas a ejercicios exploratorios
-
Por lo general, es necesario cambiar las prioridades del proceso cuando un proceso ocupa demasiado tiempo de CPU. Usando
ps
con opciones estándar para imprimir todos los procesos del sistema en formato largo, ¿qué valor de--sort
ordenará los procesos por uso de CPU, aumentando el orden?$ ps -el --sort=pcpu
-
El comando
schedtool
puede establecer todos los parámetros de programación de la CPU de los que Linux es capaz o mostrar información para procesos dados. ¿Cómo se puede utilizar para mostrar los parámetros de programación del proceso1750
? Además, ¿cómo se puede usarschedtool
para cambiar el proceso 1750 a tiempo real con prioridad -90 (como se muestra entop
)?$ schedtool 1750
$ schedtool -R -p 89 1750