Linux sans magie #21 — nice et renice : comprendre et ajuster la priorité des processus

Dans l’article sur les processus et les PID, nous avons vu comment identifier ce qui tourne. Dans celui sur les jobs du shell, nous avons appris à déplacer une commande entre premier plan et arrière-plan. Il reste une autre question très concrète : comment demander au système qu’un processus soit plus ou moins favorisé pour l’accès au CPU ?

Sous Linux, les commandes nice et renice permettent d’agir sur la niceness d’un processus. Le nom est trompeur au début : une valeur nice plus élevée ne veut pas dire « plus prioritaire ». C’est l’inverse dans l’usage courant.

L’objectif de cet article est de comprendre ce que représente cette valeur, de l’observer avec ps, puis de la modifier proprement sans confondre niceness, priorité affichée et ordonnancement temps réel.

Contexte et problème

Imaginez une machine qui exécute plusieurs tâches en même temps : une application interactive, un traitement de données et une commande de maintenance longue.

Vous pouvez vouloir que la tâche de maintenance continue à tourner, mais qu’elle laisse davantage de CPU aux autres charges lorsqu’il y a concurrence.

C’est précisément le type de besoin auquel répond la niceness.

Elle ne fixe pas une quantité de CPU garantie et ne transforme pas un processus en tâche temps réel. Elle constitue une indication utilisée par l’ordonnanceur pour départager des tâches dans les politiques d’ordonnancement classiques.

Concept ou architecture

La valeur nice

Sous Linux, la plage usuelle de niceness est :

-20 ... 0 ... 19

La règle pratique est :

valeur nice plus basse  → processus davantage favorisé
valeur nice plus haute  → processus moins favorisé

Une valeur 0 est courante pour un processus lancé normalement.

Une valeur 10 signifie qu’on demande au système d’être plus « gentil » avec les autres tâches, donc de moins favoriser ce processus lorsqu’il faut partager le CPU.

Une valeur négative comme -5 va dans l’autre direction : elle demande à favoriser davantage le processus. Cette opération est soumise à des privilèges ou à des limites de ressources spécifiques.

Niceness et priorité ne sont pas des synonymes parfaits

Vous rencontrerez souvent les colonnes NI et PRI dans les outils de processus.

Avec ps :

ps -o pid,ni,pri,comm -p <PID>

NI représente la nice value.

PRI représente une priorité telle qu’exposée par ps. Sa valeur dépend de la politique et de l’implémentation de l’ordonnanceur ; il ne faut donc pas lire NI et PRI comme deux noms pour la même donnée.

Pour l’administration courante décrite ici, la valeur à manipuler avec nice et renice est NI.

nice agit au lancement

La commande nice sert à lancer une nouvelle commande avec une niceness ajustée.

Exemple :

nice -n 10 sleep 300

Ici, sleep est lancé avec une niceness augmentée de 10 par rapport à la valeur de départ applicable.

Sur un shell classique où la niceness courante vaut 0, le processus apparaît donc généralement avec NI=10.

renice agit sur un processus déjà lancé

Pour un processus existant, on utilise renice.

Exemple :

renice 15 -p <PID>

Cette commande demande une nice value de 15 pour le PID indiqué avec l’implémentation Linux courante de renice issue d’util-linux.

Cette syntaxe volontairement simple évite d’introduire ici les variantes relatives et leurs différences historiques ou POSIX.

Prérequis

Le lab nécessite :

• un système Linux ;
• un shell interactif ;
• les commandes sleep, ps, nice et renice ;
• aucun privilège particulier pour augmenter la nice value de vos propres processus.

Vérifiez les commandes :

command -v sleep
command -v ps
command -v nice
command -v renice

Le lab ne nécessite pas sudo.

Mise en pratique

1. Observer un processus normal

Lancez un processus temporaire :

sleep 300 &

Récupérez son PID :

pid=$!

Puis affichez sa niceness et sa priorité :

ps -o pid,ni,pri,comm -p "$pid"

Résultat attendu

Vous devez obtenir une ligne contenant le PID de sleep, avec notamment les colonnes NI et PRI.

Exemple de forme générale :

    PID  NI PRI COMMAND
  12345   0  19 sleep

Les valeurs exactes de PRI peuvent varier selon le système et ne doivent pas être utilisées comme constante de référence pour le lab.

2. Terminer ce premier processus

Nettoyez le processus :

kill "$pid"
wait "$pid" 2>/dev/null || true

Puis vérifiez qu’il n’est plus présent :

ps -p "$pid"

ps ne doit plus afficher ce processus.

3. Lancer une commande avec une niceness plus élevée

Lancez maintenant :

nice -n 10 sleep 300 &

Récupérez son PID :

pid=$!

Puis observez-le :

ps -o pid,ni,pri,comm -p "$pid"

Résultat attendu

Dans un environnement où le shell démarre à NI=0, vous devez généralement observer :

NI = 10

Le point important n’est pas la colonne PRI, mais le fait que la nice value est plus élevée que celle du premier processus.

4. Modifier un processus existant avec renice

Demandez maintenant une nice value de 15 :

renice 15 -p "$pid"

Puis vérifiez :

ps -o pid,ni,pri,comm -p "$pid"

Vous devez voir :

NI = 15

Cette modification rend le processus encore moins favorisé lors de la concurrence CPU.

5. Comprendre la limite des droits

Un utilisateur ordinaire peut généralement augmenter la nice value de ses propres processus, donc les rendre moins prioritaires.

En revanche, tenter de diminuer la nice value pour rendre un processus plus favorisé peut échouer :

renice 0 -p "$pid"

Si le processus est actuellement à 15, cette commande demande une valeur plus basse et donc une priorité relative plus forte.

Selon les privilèges et les limites du compte, le système peut refuser l’opération avec un message de permission.

Ne contournez pas ce refus dans le lab. Son objectif est justement de montrer que l’augmentation de priorité est contrôlée.

Vérification

Le lab est réussi si vous pouvez observer cette progression :

processus normal
NI proche de la valeur habituelle du shell
        ↓
nice -n 10
        ↓
processus lancé avec une niceness plus élevée
        ↓
renice 15 -p PID
        ↓
NI = 15
        ↓
tentative de revenir vers une valeur plus basse
        ↓
possible refus si les privilèges ne le permettent pas

Bonnes pratiques

Avant toute modification, observez la valeur actuelle :

ps -o pid,user,ni,pri,comm -p <PID>

Modifiez ensuite uniquement le processus que vous avez identifié.

Pour une tâche de fond non critique, augmenter modérément la niceness peut être utile afin qu’elle concurrence moins fortement les tâches interactives ou sensibles à la latence.

Évitez cependant de considérer nice comme un mécanisme de quota ou de garantie. Une niceness différente influence l’ordonnancement, mais ne promet pas un pourcentage fixe de CPU.

Pour des besoins de contrôle de ressources plus stricts, d’autres mécanismes existent, notamment les cgroups et les propriétés systemd. Ils sont volontairement hors périmètre ici.

Sécurité

Augmenter la priorité d’un processus peut dégrader les performances des autres charges. C’est pour cette raison que la diminution de la nice value est contrôlée.

Sous Linux, l’augmentation de priorité peut nécessiter la capability CAP_SYS_NICE. Depuis Linux 2.6.12, une configuration appropriée de RLIMIT_NICE peut également autoriser certains ajustements à un processus non privilégié.

Dans une procédure d’exploitation, n’utilisez pas sudo renice par réflexe. Commencez par déterminer si le changement est réellement nécessaire et quel processus doit être concerné.

La niceness ne change ni l’identité utilisateur du processus, ni ses permissions sur les fichiers, ni ses privilèges applicatifs.

Coûts

Le lab n’utilise aucune ressource facturable particulière.

Dans un environnement cloud ou mutualisé, réduire ou augmenter la niceness ne modifie pas directement la tarification de la machine. Le processus continue néanmoins à consommer les ressources qu’il utilise réellement.

Une niceness plus élevée n’est donc pas un mécanisme d’économie garanti.

Limites et points de vigilance

Cet article traite uniquement de la niceness et des commandes classiques nice et renice.

Il ne couvre pas :

• chrt ;
• SCHED_FIFO ;
• SCHED_RR ;
• les politiques temps réel ;
• l’affinité CPU ;
• les cgroups et quotas CPU ;
• les paramètres systemd de contrôle CPU.

La niceness ne doit pas être confondue avec une priorité temps réel. Le manuel GNU Coreutils rappelle qu’une niceness est un conseil à l’ordonnanceur plutôt qu’une garantie absolue d’ordre d’exécution.

Autre point : renice possède plusieurs syntaxes et conventions historiques. L’implémentation Linux d’util-linux distingue notamment la définition d’une priorité et les ajustements relatifs. Pour rester reproductible, cet article utilise uniquement une forme explicite avec une valeur cible et -p.

Enfin, la réaction réelle d’une charge dépend du niveau de concurrence CPU, de la politique d’ordonnancement et de la configuration du système. Sur une machine presque inactive, modifier la niceness peut produire peu de différence observable.

Rollback ou nettoyage

Le lab utilise uniquement des processus sleep temporaires.

Pour terminer le dernier processus :

kill "$pid"
wait "$pid" 2>/dev/null || true

Vérifiez ensuite :

ps -p "$pid"

Il ne doit plus apparaître.

Aucun fichier ni service permanent n’est créé.

Si vous avez modifié la niceness d’un processus réel en dehors du lab, ne supposez pas que vous pourrez toujours restaurer une valeur plus basse sans privilèges. Vérifiez d’abord les droits disponibles et l’impact opérationnel.

Références officielles

• GNU Coreutils — nice invocation — GNU Project
• renice(1) — util-linux — util-linux / Linux manual pages
• getpriority(2), setpriority(2) — Linux man-pages
• nice(2) — Linux man-pages

Conclusion

nice et renice deviennent simples dès que l’on retient une règle : plus la nice value est élevée, plus le processus accepte de laisser la place aux autres.

nice agit au lancement d’une commande. renice modifie un processus existant. ps permet ensuite de vérifier la valeur NI réellement appliquée.

Le point essentiel est de ne pas transformer cette valeur en promesse de CPU ou en priorité temps réel. C’est un mécanisme utile pour influencer l’ordonnancement classique, pas pour remplacer les outils de contrôle de ressources ou les politiques temps réel.

---