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

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.

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

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.