Nice, priorités et limites

Prérequis : cours précédent.

Pourquoi

Un batch qui affame l'API, c'est un problème de priorités pas de puissance. nice coûte zéro et sauve des prod — à condition de comprendre ce qu'il fait (et ne fait pas).

Concepts

• nice (-20 à +19) : la « gentillesse » CPU. Défaut 0 ; batch en nice 10 (prioritaire bas) ; temps réel en négatif (root seul). Ne donne PAS de CPU garanti : ça départage les concurrents, un process seul prend tout même à +19.
• ionice : pareil pour le disque (classes idle/best-effort/rt). Backup en ionice -c3 (idle : que le disque inutilisé) : invisible pour la prod.
• ulimit : plafonds par process (fichiers ouverts nofile, process nproc, taille…). Too many open files = ulimit, pas bug applicatif ! Vérifier : ulimit -n, cat /proc/<pid>/limits.
• cgroups v2 (aperçu, détaillé cours 3.x/systemd) : l'ancrage moderne des limites (mémoire, CPU, I/O) — ce que Docker utilise sous le capot.

Exemple : batch poli

nice -n 10 ionice -c3 tar czf /backups/data.tgz /data
# CPU basse priorité + disque idle : la prod ne voit rien
ulimit -n 65535   # par shell/processus (persistant via limits.conf/systemd !)

Cas réel

Compression de 200 Go lancée à 14h sans nice : load 40, API à genoux 2 h. Relancée en nice 19 ionice -c3 : load 3, invisible. Même travail, autre politesse — zéro euro.

Pièges

• nice négatif sans besoin : affamer le système pour un batch = inversion des priorités. Négatif = temps réel justifié seulement.
• ulimit dans le shell mais pas dans le service : le service systemd a SES limites (LimitNOFILE= dans l'unit !). Configurer au bon endroit.
• Croire que nice garantit : seul face au CPU, même à +19, il prend tout. C'est du partage, pas du quota (quotas = cgroups).

À retenir

Batch en nice/ionice, ulimit vérifié au bon endroit (unit systemd !), quotas = cgroups.