cgroups : comprendre les limites modernes

Prérequis : cours précédent.

Pourquoi

Docker, systemd, Kubernetes limitent tous via cgroups : comprendre le mécanisme, c'est diagnostiquer « pourquoi mon conteneur est tué » au lieu d'accuser l'appli.

Concepts

• Hiérarchie : /sys/fs/cgroup/ — chaque service/conteneur a son groupe avec ses compteurs et limites (mémoire, CPU, I/O, pids).
• OOM du groupe : limite mémoire atteinte → le noyau tue dans le groupe (memory.events : max incrémenté = preuve !). Ce n'est PAS l'OOM-killer global : c'est TA limite qui mord.
• CPU : cpu.max (quota/période : 50000 100000 = 0,5 CPU), cpu.weight (part relative en concurrence). Throttle = ralenti, pas tué.
• Pression (PSI) : /proc/pressure/{cpu,memory,io} — le % de temps où les tâches ATTENDENT. La métrique moderne : some avg10 > 30 = saturation réelle, mieux que load average.

Exemple : diagnostiquer un kill

cat /sys/fs/cgroup/system.slice/mon-app/memory.events  # max > 0 ? = limite mordue
cat /proc/pressure/memory   # some avg10 élevé ? = vraie pression mémoire
systemd-cgtop               # top par cgroup : qui consomme quoi

Cas réel

Conteneur « qui crash sans logs » : exit 137 (128+9 = SIGKILL). memory.events:max incrémenté pile aux crashs = limite trop basse, pas bug applicatif. Limite ×2 : stabilité retrouvée. Exit 137 = toujours suspecter la mémoire d'abord.

Pièges

• Exit 137 = SIGKILL = presque toujours mémoire (limite ou OOM global). Chercher là d'abord.
• cpu.weight sans concurrence : aucun effet visible (comme nice). Les parts ne jouent qu'en compétition.
• Limites systemd vs Docker qui se cumulent : la plus basse gagne, des deux côtés à vérifier.

À retenir

memory.events = preuve, exit 137 = mémoire d'abord, PSI = saturation réelle, throttled ≠ tué.