Uso y comprensión de las opciones relacionadas con la programación systemd en un contexto de escritorio


14

En los archivos de servicio systemd, uno puede configurar las siguientes opciones relacionadas con la programación (desde la systemd.execpágina del manual , corríjame si me equivoco):

Nice Establece el nivel agradable predeterminado (prioridad de programación) para los procesos ejecutados. Toma un número entero entre -20 (prioridad más alta) y 19 (prioridad más baja). Ver setpriority (2) para más detalles.

Cuál es el nivel agradable familiar. Parece que su efecto está 'subvertido' de alguna manera debido a la característica de 'grupo automático' de los últimos núcleos de Linux. Por lo tanto, las opciones a continuación pueden ser lo que realmente me gustaría establecer para que los procesos se comporten bien para mi experiencia de escritorio.

CPUSchedulingPolicy Establece la política de programación de la CPU para los procesos ejecutados. Toma uno de otro, lote, inactivo, fifo o rr. Ver sched_setscheduler (2) para más detalles.

CPUSchedulingPriority Establece la prioridad de programación de la CPU para los procesos ejecutados. El rango de prioridad disponible depende de la política de programación de CPU seleccionada (ver arriba). Para las políticas de programación en tiempo real, se puede utilizar un número entero entre 1 (prioridad más baja) y 99 (prioridad más alta). Ver sched_setscheduler (2) para más detalles.

CPUSchedulingResetOnFork Toma un argumento booleano. Si es cierto, las prioridades y políticas de programación de CPU elevadas se restablecerán cuando los procesos ejecutados se bifurcan, y por lo tanto no pueden filtrarse en procesos secundarios. Ver sched_setscheduler (2) para más detalles. Por defecto es falso.

Entiendo la última opción. De la explicación de los dos primeros deduzco que puedo elegir una política de programación y luego, dada esa política, una prioridad. No está del todo claro para mí qué debo elegir para qué tipo de tareas. Por ejemplo, ¿es seguro elegir 'inactivo' para tareas de copia de seguridad (relativamente intensivo de CPU, debido a la deduplicación), o es otro más adecuado?

En general, lo que busco es obtener una visión general comprensible de cada política, con cada una de sus prioridades e idoneidad para fines específicos. También la interacción con el nivel agradable es de interés.

Junto a la programación de la CPU, hay programación de E / S. Supongo que esto corresponde a ionice(corrígeme si me equivoco).

IOSchedulingClass Establece la clase de programación de E / S para procesos ejecutados. Toma un número entero entre 0 y 3 o una de las cadenas ninguna, en tiempo real, mejor esfuerzo o inactivo. Ver ioprio_set (2) para más detalles.

IOSchedulingPriority Establece la prioridad de programación de E / S para los procesos ejecutados. Toma un número entero entre 0 (prioridad más alta) y 7 (prioridad más baja). Las prioridades disponibles dependen de la clase de programación de E / S seleccionada (ver arriba). Ver ioprio_set (2) para más detalles.

Aquí vemos la misma estructura que con la programación de la CPU. Estoy buscando el mismo tipo de información también.

Para todas las opciones de 'Programación', las páginas de manual referidas no son lo suficientemente claras para mí, principalmente al traducir cosas a un punto de vista de usuario de escritorio algo inclinado técnicamente.


2
¿Qué problema de rendimiento en particular estás tratando de resolver? ¿Hay algo corriendo demasiado lento o con demasiado retraso para ti? Utilizo Ubuntu 16.04 con systemd como escritorio, con copias de seguridad ejecutándose en segundo plano y no tengo problemas de rendimiento relacionados con la prioridad relativa.
Mark Stosberg el

@MarkStosberg La pregunta fue provocada por los trabajos de respaldo en segundo plano que se ejecutaban mientras las tareas computacionales en primer plano en un sistema de doble núcleo hacían que la interfaz no respondiera. Luego agregué una buena opción al script de copia de seguridad y al mismo tiempo vi las otras opciones. Pueden ser relevantes para ese problema causado por la copia de seguridad u otros problemas que encuentre en el futuro. Por lo tanto, me gustaría aprender más sobre esas otras opciones, sin que esté relacionado con un problema concreto.
Equaeghe

Cada bit de documentación hace referencia a una página de manual donde puede encontrar más documentación si está interesado. ¿La lectura de las páginas man referenciadas para ioprio_set (2) y sched_setscheduler (2) ayuda a responder sus preguntas?
Mark Stosberg

@ MarkStosberg No, como se indica en mi pregunta. Las páginas de manual no son malas, pero no necesariamente me ayudan a decidir qué hacer (¿ajustar los valores agradables sigue siendo lo más seguro / correcto que hacer hoy en día?). Espero respuestas de usuarios experimentados de estas opciones que pueden dar ejemplos concretos y conocer el impacto del autogrupo en tales casos concretos.
Equaeghe

Me topé con estas directivas en casi el mismo contexto (las copias de seguridad en segundo plano causan retraso). Descubrí que man sched (7) tiene una descripción mucho más completa de las otras dos páginas de manual. (También menciona cuándo se niceaplica el valor).
Wisperwind

Respuestas:


5

CPUScheduling {Policy | Priority}

El enlace le dice que CPUSchedulingPrioritysolo debe configurarse para tareas ( fifoo rr"en tiempo real"). No desea forzar la programación en tiempo real de los servicios.

CPUSchedulingPolicy=other es el predeterminado

Eso se va batchy idle. La diferencia entre ellos solo es relevante si tiene varias tareas de prioridad inactiva que consumen CPU al mismo tiempo. En teoría, batchproporciona un mayor rendimiento (a cambio de latencias más largas). Pero no es una gran victoria, por lo que no es realmente relevante en este caso.

idleliteralmente muere de hambre si algo más quiere la CPU. La prioridad de la CPU es bastante menos significativa de lo que solía ser, para sistemas UNIX antiguos con un solo núcleo. Sería más feliz comenzar con nice, por ejemplo, un buen nivel 10 o 14, antes de recurrir idle. Ver la siguiente sección.

Sin embargo, la mayoría de los escritorios están relativamente inactivos la mayor parte del tiempo. Y cuando tienes un CPU hog que se adelanta a la tarea en segundo plano, es común que el hog solo use una de tus CPU. Con eso en mente, no me sentiría demasiado arriesgado usarlo idleen el contexto de una computadora de escritorio o portátil promedio. A menos que tenga una CPU Atom / Celeron / ARM con una potencia nominal de 15 vatios o inferior ; entonces me gustaría ver las cosas un poco más cuidadosamente.

¿Es agradable el nivel 'subvertido' por la función 'autogrupo' del núcleo?

Si.

La agrupación automática es un poco rara. Al autor de systemdno le gustó la heurística, incluso para computadoras de escritorio. Si desea probar deshabilitar la agrupación automática, puede configurar el sysctl kernel.sched_autogroup_enabled en 0. Supongo que es mejor probar configurando el sysctl en configuración permanente y reiniciando, para asegurarse de deshacerse de todos los grupos automáticos.

Entonces deberías poder obtener buenos niveles de tus servicios sin ningún problema. Al menos en las versiones actuales de systemd: consulte la siguiente sección.

Por ejemplo, un buen nivel 10 reducirá el peso que cada subproceso tiene en el programador de CPU de Linux, a aproximadamente el 10%. Buen nivel 14 es inferior al 5%. (Enlace: fórmula completa )

Apéndice: ¿el nivel agradable es 'subvertido' por systemd cgroups?

La DefaultCPUAccounting= configuración actual está desactivada por defecto, a menos que se pueda habilitar sin habilitar también el control de la CPU por servicio. Entonces debería estar bien. Puede verificar esto en su documentación actual:man systemd-system.conf

Tenga en cuenta que el control de CPU por servicio también se habilitará cuando cualquier servicio establezca CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

El siguiente extracto del blog está desactualizado (pero aún en línea). El comportamiento predeterminado ha cambiado desde entonces, y la documentación de referencia se ha actualizado en consecuencia.

Por defecto, si el controlador de la CPU está habilitado en el kernel, systemd creará un cgroup para cada servicio al iniciarlo. Sin ninguna configuración adicional, esto ya tiene un buen efecto: en un sistema systemd, cada servicio del sistema obtendrá una cantidad uniforme de CPU, independientemente de cuántos procesos consista. O en otras palabras: en su servidor web, MySQL obtendrá aproximadamente la misma cantidad de CPU que Apache, incluso si este último consta de 1000 procesos de script CGI, pero el primero solo de unas pocas tareas de trabajo. (Este comportamiento se puede desactivar, consulte DefaultControllers = en /etc/systemd/system.conf).

Además de este valor predeterminado, es posible configurar explícitamente los recursos compartidos de CPU que un servicio obtiene con la configuración CPUShares =. El valor predeterminado es 1024; si aumenta este número, asignará más CPU a un servicio que uno inalterado a 1024; si lo disminuye, menos.

http://0pointer.de/blog/projects/resources.html


-3

El clásico consejo de ajuste de ejecución es "Don't Optimize, Benchmark".

En lugar de preocuparse por los consejos generales, comience con un caso específico que le preocupe mejorar y que haya sido evaluado como un problema de rendimiento específico . Deje que los datos le permitan ajustar la directiva correcta. Con los datos, puede quedar claro si su proceso tiene una mala prioridad, está acaparando la CPU o tiene otro problema.

Los escritorios modernos a menudo son bastante rápidos para trabajar sin ningún ajuste en absoluto.


3
Lo sentimos, pero esta no es una respuesta a la pregunta. El punto es que probar las cosas es difícil si uno realmente no comprende los efectos. Y esta pregunta fue provocada por (¡pero no se trata!) Problemas de rendimiento en un escritorio moderno.
Equaeghe

1
En solo toma unos minutos probar cualquiera de las opciones. Si tiene un punto de referencia de referencia y un objetivo de rendimiento, puede verificar fácilmente si la opción que probó lo mueve en la dirección que desea.
Mark Stosberg el

@equaeghe, tocar botones aleatorios sin saber lo que hacen tampoco resolverá el problema.
vonbrand

Amplio consejo, pero no una respuesta. Esto debería ser más bien un comentario. A veces, la sensación de "esto es muuuuuuuuuuuuuuuuuuuuuuuu como demasiado lento" es un punto de referencia suficiente para impulsar la acción. Por ejemplo, usar systemd-analyzecon blamey plotpude reducir el tiempo de arranque en un RPi anterior en más de un minuto. Claro, cuando se trata del análisis del problema, se requiere medir en lugar de comenzar prematuramente la "optimización".
0xC0000022L
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.