Los procesos de Linux pueden tener diferentes CPU y prioridad de E / S (agradable e ionizante).
¿Por qué es necesario tener una CPU diferente y prioridad de E / S?
¿Hay algún uso en el mundo real para tenerlos diferentes?
¿Qué casos de uso del mundo real ha encontrado que necesitan una CPU y una prioridad de E / S diferentes? Como una prioridad de CPU superior a la normal pero inferior a la prioridad de E / S normal o viceversa.
Respuestas:
El comportamiento predeterminado de 'nice' es ajustar la prioridad 'io' de la aplicación también cuando la amabilidad cambia.
Por supuesto, todo depende de su carga de trabajo, pero uno de los aspectos clave de cualquier sistema operativo es cómo asigna sus recursos y cómo maneja la contención .
Es realmente importante entender lo que hace la amabilidad porque, cuando está bajo carga de procesos competitivos, la forma en que se comporta el sistema operativo puede tener un impacto en el resto de su carga de trabajo.
La contención es la medida de cómo las diferentes aplicaciones compiten por el mismo recurso (como la CPU).
Carga de manejo
Desde que se introdujo el planificador completamente justo, nice es simplemente una interfaz para la cláusula de 'peso' de cada proceso. Que se puede ver en proc.
$ cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 1024
...
Cambiar la amabilidad simplemente altera el peso:
$ nice -n 5 cat /proc/self/sched
---------------------------------------------------------
...
se.load.weight : 335
...
La medida para la contención de la CPU se realiza mediante el algoritmo de programación completamente justo. A cada aplicación se le asigna un valor de "peso" y, en el caso de un tiempo de CPU en conflicto, el tiempo se divide entre los procesos al sumar todos los contendientes de procesamiento para el tiempo de CPU y asignarles el tiempo de CPU de denominación común más bajo en función de su valor de peso.
Si tengo 3 aplicaciones que desean usar el tiempo de CPU, por defecto reciben 1024 como peso normal. Si tengo un proceso con un agradable +5 como el anterior, los tres pesos se sumarían en 2383, el proceso indicado recibiría aproximadamente el 15% del tiempo de CPU en un segundo dado si los 3 procesos solicitaran la CPU en ese segundo .
¿Por qué es necesario tener una CPU diferente y prioridad de E / S?
La simpatía realmente solo es jugar con qué hacer cuando el sistema está bajo carga, es decir, cómo el sistema operativo divide el tiempo entre procesos competidores según lo definido por los factores que sean necesarios.
La forma en que esto le afecta o es relevante para usted depende de las prioridades de entrega que tengan las diferentes aplicaciones entre sí y el tiempo que debe tener para entregar cada aplicación.
Niceness realmente solo hace algo cuando su sistema está bajo carga (hay más cosas que requieren atención de las que la CPU o el Disco pueden manejar). Simplemente le indica al núcleo cómo asignar recursos en esas circunstancias.
¿Hay algún uso en el mundo real para tenerlos diferentes?
Si tiene numerosos procesos competitivos o trabajo por hacer que es más de lo que puede hacer la CPU, la amabilidad le brinda algunas garantías relativamente estables en cuanto a qué trabajo termina primero. Esto puede ser importante para usted si dice que produce un informe que debe entregarse antes de que finalice otro informe.
En un sistema de escritorio, la simpatía puede ser aún más importante. Ciertas aplicaciones tienen un comportamiento en tiempo real, por lo que se activan con mayor frecuencia durante la carga evita que los datos se vuelvan obsoletos. Pulseaudio entra en esta categoría, por ejemplo.
Es posible que se requieran otras aplicaciones para distribuir el trabajo para aplicaciones dependientes. Por ejemplo, muchas solicitudes de Apache para decir que un servidor SQL como MySQL puede bloquearse durante un largo período de tiempo porque SQL no está funcionando lo suficientemente rápido porque, digamos, algún otro informe está compitiendo por el tiempo de CPU. Entonces, no solo SQL está estancado, sino también Apache. SQL puede doler aquí a veces porque generalmente hay muchos menos subprocesos de trabajo que subprocesos apache compitiendo como un grupo para que el planificador los considere más favorablemente, por lo que dar más tiempo de CPU a SQL iguala las cosas.
UpdateDB (un programa que indexa archivos) se ejecuta tarde en la noche y es muy pesado en disco. Puede ser útil reducir su prioridad de programación de E / S para que otras aplicaciones en ese momento tengan prioridad sobre algo que no es tan importante en el orden de las cosas.
¿Qué casos de uso del mundo real ha encontrado que necesitan una CPU y una prioridad de E / S diferentes?
Muy pocos. La amabilidad es demasiado de un enfoque de mejor esfuerzo. Como regla general, me importa menos acerca de lo bien que realizan aplicaciones y más de lo mal que podrían llevar a cabo. Al principio, esto puede sonar al revés, pero tengo garantías de entrega de servicios que son más importantes para mí.
Quiero la confianza de decir "tus cosas incluso en un mal día se harán en un período de tiempo X". Si va más rápido, es solo una ventaja.
Normalmente comenzaré generando especificaciones acordadas como:
Y dibuja requisitos para cumplir como:
Si las especificaciones son verdaderas, cumplo con estos objetivos sin hacer virtualización, utilizando el enfoque mucho más eficiente de los grupos de control.
Los grupos de control me permiten hacer garantías de nivel de servicio bastante confiables para la asignación de recursos siempre que la aplicación se comporte dentro de los límites especificados. ¡Esto significa que incluso en un sistema bajo carga puedo garantizar la disponibilidad de recursos para la aplicación en cuestión y garantizar espacio para otras aplicaciones en la misma caja!
Si tomamos su ejemplo de CPU e IO. Establecí límites que cumplen con esos requisitos:
# cd /sys/fs/cgroup/blkio/apache
# echo "253:0 100" >blkio.throttle.read_iops_device
# echo "253:0 50" >blkio.throttle.write_iops_device
# echo "253:0 102400" >blkio.throttle.read_bps_device
Entonces 100k bytes para leer de 100 iops.
# cd /sys/fs/cgroup/cpu/apache
# echo 1000000 >cpu.cfs_period_us
# echo 60000 >cpu.cfs_quota_us
De un período de tiempo de 1 segundo, dé 0.06 segundos de CPU.
# cd /sys/fs/cgroup/cpu/sql
# echo 1000000 >cpu.cfs_period_us
# echo 20000 >cpu.cfs_quota_us
De un período de tiempo de 1 segundo, dé 0.02 segundos de CPU.
Proporcionar otros cgroups competidores no hace nada tonto, estar bajo carga es un factor menos importante en la entrega de mi servicio porque sé cómo se lanza la CPU para cada aplicación.
Los grupos de control de esta naturaleza siguen siendo el mejor esfuerzo, pero ofrecen mucho más control sobre ese esfuerzo que la simpatía y la ionización.