Utilisation et compréhension des options liées à la planification de Systemd dans un contexte de bureau

Dans les fichiers de service systemd, on peut définir les options liées à la planification suivantes (à partir de la systemd.execpage de manuel , corrigez-moi si je me trompe):

Nice Définit le niveau de nice par défaut (priorité de planification) pour les processus exécutés. Prend un entier entre -20 (priorité la plus élevée) et 19 (priorité la plus faible). Voir setpriority (2) pour plus de détails.

Quel est le niveau agréable familier. Il semble que son effet soit quelque peu «subverti» en raison de la fonction «autogroupe» des noyaux Linux récents. Donc, les options ci-dessous peuvent être ce que je voudrais vraiment définir pour que les processus se comportent bien pour mon expérience de bureau.

CPUSchedulingPolicy Définit la politique de planification du processeur pour les processus exécutés. Prend l'un des autres, batch, inactif, fifo ou rr. Voir sched_setscheduler (2) pour plus de détails.

CPUSchedulingPriority Définit la priorité de planification du processeur pour les processus exécutés. La plage de priorité disponible dépend de la politique de planification du processeur sélectionnée (voir ci-dessus). Pour les politiques de planification en temps réel, un entier compris entre 1 (priorité la plus basse) et 99 (priorité la plus élevée) peut être utilisé. Voir sched_setscheduler (2) pour plus de détails.

CPUSchedulingResetOnFork Prend un argument booléen. Si la valeur est vraie, les priorités et politiques de planification du processeur élevées seront réinitialisées lorsque les processus exécutés se bifurquent et ne peuvent donc pas s'infiltrer dans les processus enfants. Voir sched_setscheduler (2) pour plus de détails. La valeur par défaut est false.

Je comprends la dernière option. Je comprends de l'explication des deux premiers que je peux choisir une politique de planification puis, étant donné cette politique, une priorité. Je ne sais pas très bien ce que je devrais choisir pour quel type de tâches. Par exemple, est-il sûr de choisir «inactif» pour les tâches de sauvegarde (relativement gourmand en CPU, car dédupliqué), ou un autre est-il mieux adapté?

En général, je recherche un aperçu compréhensible de chaque politique, de chacune de ses priorités et de son adéquation à des fins spécifiques. L'interaction avec le niveau agréable est également intéressante.

À côté de la planification du processeur, il y a la planification des E / S. Je suppose que cela correspond à ionice(corrigez-moi si je me trompe).

IOSchedulingClass Définit la classe de planification d'E / S pour les processus exécutés. Prend un entier entre 0 et 3 ou l'une des chaînes aucune, en temps réel, au mieux ou au repos. Voir ioprio_set (2) pour plus de détails.

IOSchedulingPriority Définit la priorité de planification des E / S pour les processus exécutés. Prend un entier entre 0 (priorité la plus élevée) et 7 (priorité la plus basse). Les priorités disponibles dépendent de la classe de planification d'E / S sélectionnée (voir ci-dessus). Voir ioprio_set (2) pour plus de détails.

Nous voyons ici la même structure qu'avec la programmation CPU. Je recherche également le même type d'informations.

Pour toutes les options de «planification», les pages de manuel auxquelles je me réfère ne sont pas assez claires pour moi, principalement dans la traduction des choses au point de vue d'un utilisateur de bureau quelque peu technique.

CPUScheduling {Policy | Priority}

Le lien vous indique que cela CPUSchedulingPriorityne doit être défini que pour fifoou rr("en temps réel") des tâches. Vous ne souhaitez pas forcer la planification en temps réel sur les services.

CPUSchedulingPolicy=other est la valeur par défaut.

Cela laisse batchet idle. La différence entre eux n'est pertinente que si vous avez plusieurs tâches de priorité inactive consommant du CPU en même temps. En théorie, batchdonne un débit plus élevé (en échange de latences plus longues). Mais ce n'est pas une grosse victoire, donc ce n'est pas vraiment pertinent dans ce cas.

idlelittéralement affamé si quelque chose d'autre veut le CPU. La priorité du processeur est plutôt moins importante qu'auparavant, pour les anciens systèmes UNIX avec un seul cœur. Je serais plus heureux de commencer avec nice, par exemple, un bon niveau 10 ou 14, avant d'y recourir idle. Voir la section suivante.

Cependant, la plupart des ordinateurs de bureau sont relativement inactifs la plupart du temps. Et lorsque vous avez un porc CPU qui préempterait la tâche d'arrière-plan, il est courant que le porc n'utilise que l'un de vos CPU. Dans cet esprit, je ne me sentirais pas trop risqué à utiliser idledans le contexte d'un ordinateur de bureau ou d'un ordinateur portable moyen. À moins qu'il n'ait un processeur Atom / Celeron / ARM évalué à 15 watts ou moins ; alors je voudrais regarder les choses un peu plus attentivement.

Le bon niveau est-il «subverti» par la fonction «autogroupe» du noyau?

Ouais.

L'autogroupage est un peu bizarre. L'auteur de systemdn'a pas aimé l'heuristique, même pour les ordinateurs de bureau. Si vous souhaitez tester la désactivation de l'autogroupage, vous pouvez définir le sysctl kernel.sched_autogroup_enabled sur 0. Je suppose qu'il est préférable de tester en définissant le sysctl en configuration permanente et en redémarrant, pour vous assurer de vous débarrasser de tous les autogroupes.

Ensuite, vous devriez être en mesure de proposer de bons niveaux pour vos services sans aucun problème. Au moins dans les versions actuelles de systemd - voir la section suivante.

Par exemple, un joli niveau 10 réduira le poids de chaque thread dans le planificateur CPU Linux à environ 10%. Le niveau 14 de Nice est inférieur à 5%. (Lien: formule complète )

Annexe: le bon niveau est-il «subverti» par les groupes de contrôle systemd?

Le DefaultCPUAccounting= paramètre actuel est désactivé par défaut, sauf s'il peut être activé sans activer également le contrôle du processeur par service. Donc ça devrait aller. Vous pouvez vérifier cela dans votre documentation actuelle:man systemd-system.conf

N'oubliez pas que le contrôle du processeur par service sera également activé lorsque n'importe quel service définit CPUAccounting / CPUWeight / StartupCPUWeight / CPUShares / StartupCPUShares.

L'extrait de blog suivant est obsolète (mais toujours en ligne). Le comportement par défaut a depuis changé et la documentation de référence a été mise à jour en conséquence.

Par défaut, si le contrôleur de processeur est activé dans le noyau, systemd créera un groupe de contrôle pour chaque service au démarrage. Sans aucune configuration supplémentaire, cela a déjà un bel effet: sur un système systemd, chaque service système recevra une quantité égale de CPU, quel que soit le nombre de processus qu'il comprend. Ou en d'autres termes: sur votre serveur Web, MySQL obtiendra à peu près la même quantité de CPU qu'Apache, même si ce dernier se compose de 1000 processus de script CGI, mais le premier de quelques tâches de travail. (Ce comportement peut être désactivé, voir DefaultControllers = dans /etc/systemd/system.conf.)

En plus de cette valeur par défaut, il est possible de configurer explicitement les partages CPU qu'un service obtient avec le paramètre CPUShares =. La valeur par défaut est 1024, si vous augmentez ce nombre, vous affecterez plus de CPU à un service qu'un non modifié à 1024, si vous le diminuez, moins.

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

Le conseil de réglage classique est "Don't Optimize, Benchmark".

Plutôt que de vous préoccuper des conseils généraux, commencez par un cas spécifique qui vous intéresse et qui a été évalué pour avoir un problème de performance spécifique . Laissez les données vous laisser sur la bonne directive à régler. Avec les données, il peut être clair si votre processus souffre d'une mauvaise priorité, monopolise le processeur ou a un autre problème.

Les ordinateurs de bureau modernes sont souvent très rapides à travailler sans aucun réglage.