Slices, ressources et priorités système

Prérequis : cours précédent (nice) ; cgroups vus au cursus DevOps 1.3 (OOM-killer).

Pourquoi

cgroups vus en 1.3 ; ici leur pilotage via systemd : slices (regroupements), parts CPU/mémoire par service, et la vue d'ensemble (systemd-cgtop). C'est l'interface propre au mécanisme brut.

Concepts

• Slices : system.slice (système), user.slice (sessions), machine.slice (VM/conteneurs). Chaque service vit dans une slice : limites par groupe, pas que par service.
• Directives : CPUQuota=50% (plafond dur !), CPUWeight= (part en concurrence), MemoryMax= (limite + OOM du groupe), IOWeight=. Dans l'unit, versionnées, visibles : mieux que des nice épars.
• systemd-cgtop : top par cgroup : qui consomme, par branche. Le premier réflexe « load haute » moderne.
• OOM du groupe : MemoryMax atteint → tué dans le groupe. memory.events : preuve (cf. 1.3).

Exemple : batch qui ne gêne jamais

[Service]
CPUQuota=30%
MemoryMax=1G
IOWeight=10

Le batch a son plafond ET sa part basse : la prod garde 70 % CPU garantis en concurrence.

Cas réel

3 applis sur un VPS 4 Go : l'une leak lentement, OOM global qui tue… la base (grosse mémoire = cible du tueur). MemoryMax par service : le leaker se fait tuer seul, la base survit. Le confinement mémoire, c'est de l'assurance.

Pièges

• CPUQuota trop bas sur service à pics (builds) : throttling permanent = builds ×5. Quota selon pics mesurés, pas au hasard.
• Limites posées sans monitoring (memory.events, alertes) : tuées en silence, incompréhension. Alerter sur les dépassements.
• Confondre Weight et Quota : weight = partage en concurrence (rien seul), quota = plafond toujours. Les deux ensemble = contrôle total.

À retenir

Slices = regroupements, Quota = plafond, Weight = partage, MemoryMax + monitoring.