Nice sous Linux : calmer un processus gourmand sans l’arrêter brutalement

Quand un processus Linux commence à manger trop de CPU, le premier réflexe ne doit pas toujours être kill. Si le service travaille vraiment, couper brutalement peut perdre une tâche, casser une sauvegarde ou interrompre un traitement en cours. Dans ce cas, nice et renice permettent de baisser sa priorité sans l’arrêter.

Attention : ces commandes ne limitent pas magiquement la charge. Elles changent la priorité CPU vue par l’ordonnanceur Linux. C’est utile pour laisser respirer le serveur, mais si une application boucle ou bloque une base de données, il faudra quand même aller lire les logs et comprendre la cause.

Comprendre la valeur nice avant de modifier un processus

Sous Linux, la valeur nice va généralement de -20 à 19. Plus la valeur est basse, plus le processus est prioritaire. Plus elle est haute, plus il laisse de la place aux autres tâches.

• -20 : priorité très élevée, à réserver aux cas maîtrisés ;
• 0 : priorité par défaut de beaucoup de processus ;
• 10 ou 15 : priorité plus basse, pratique pour une tâche longue non urgente ;
• 19 : priorité très basse.

Un utilisateur classique peut généralement rendre ses propres processus moins prioritaires. Pour donner plus de priorité à un processus, il faut des droits root. C’est volontaire : monter une priorité trop haut sur un serveur partagé peut gêner le reste du système.

Lancer une commande avec une priorité plus basse

La commande nice s’utilise au moment où vous lancez un programme. Exemple simple :

nice -n 10 commande

Pour une compression lourde, ça peut donner :

nice -n 10 tar -czf sauvegarde.tar.gz /srv/data

La tâche tourne toujours, mais elle évite de prendre la main trop agressivement sur les autres processus. Je l’utilise surtout pour des traitements de fond : compression, conversion, scan, script maison ou opération longue qui n’a pas besoin de finir dans la minute.

Si vous lancez la commande depuis un script cron ou un terminal SSH, gardez quand même un oeil sur la charge. Une priorité plus basse ne remplace pas une surveillance minimale.

Voir la priorité actuelle avec ps, top ou htop

Avant de modifier quoi que ce soit, identifiez le processus concerné. Une sortie ps ciblée suffit souvent :

ps -eo pid,ni,pri,pcpu,pmem,comm --sort=-pcpu | head

La colonne NI affiche la valeur nice. La colonne PRI donne une priorité calculée par le noyau. Pour une lecture rapide en direct, vous pouvez aussi ouvrir :

top

Ou utiliser htop pour lire la charge du serveur. Dans htop, trier par CPU puis vérifier le PID et l’utilisateur évite déjà pas mal de mauvaises décisions.

Modifier un processus déjà lancé avec renice

Si le processus tourne déjà, nice ne suffit plus. Il faut utiliser renice. Commencez par récupérer le PID, puis baissez la priorité :

renice +10 -p 1234

Ici, 1234 doit être remplacé par le PID réel. Sur un processus qui appartient à un autre utilisateur, ou si vous voulez augmenter sa priorité, passez par sudo :

sudo renice -5 -p 1234

Je vous déconseille de mettre des valeurs négatives sans raison précise. Sur un serveur en production, c’est rarement la bonne première réponse. Baisser la priorité d’un traitement lourd est souvent plus sain que donner un passe-droit CPU à un service mal diagnostiqué.

Vérifier que le changement est pris en compte

Après un renice, relisez la valeur NI :

ps -o pid,ni,pri,pcpu,pmem,comm -p 1234

Vous pouvez aussi regarder la charge globale :

uptime

Si le serveur reste lent, ne concluez pas trop vite que renice ne fonctionne pas. Le goulot peut venir du disque, de la mémoire, d’un verrou applicatif ou d’un service qui redémarre en boucle. Dans ce cas, vérifiez les journaux avec journalctl et les logs applicatifs avec tail.

Quand nice ne suffit pas

nice et renice agissent sur la priorité CPU. Ils ne limitent pas la mémoire, ne corrigent pas une requête SQL folle et ne remplacent pas une vraie limite de ressources. Si vous devez encadrer proprement un service, regardez plutôt du côté de systemd, des cgroups ou de la configuration de l’application.

Si le processus est clairement bloqué ou dangereux, il faudra peut-être l’arrêter. Dans ce cas, reprenez la méthode propre : identifier le service, lire les logs, tenter un arrêt normal, puis seulement ensuite utiliser kill sans couper le mauvais processus.

Les pages de manuel de nice, renice et ps détaillent les options disponibles. En pratique, retenez surtout cette règle : baissez la priorité d’une tâche longue si elle gêne le serveur, mais ne l’utilisez pas pour masquer un vrai problème de charge.