Limites de ressources Docker : empêcher une fuite mémoire de faire tomber le serveur

L’alarme du téléphone sonne — « serveur ne répond pas », « CPU 100 % », « timeout SSH ». Trois tentatives VPN avant de se connecter, la commande ssh — timeout. Le serveur est bloqué.

Après un redémarrage forcé, les logs révèlent la cause : un conteneur tournant depuis six mois avec une fuite mémoire, passé de 500 Mo à 16 Go, ayant épuisé toute la RAM. SSH n’avait plus de ressources pour répondre. Trois autres conteneurs normaux sont tombés avec lui — la production s’est effondrée. En 2024, Docker 27.0.3 a révélé un bug grave de fuite mémoire : 68 conteneurs tués d’un coup par l’OOM Killer.

Cet article répond à une question claire : comment empêcher un seul conteneur de faire tomber le serveur. Des cgroups en bas niveau aux paramètres --memory et --cpus, en passant par docker stats, cAdvisor et Prometheus — tout sur les limites de ressources Docker. Après lecture, vous saurez au minimum faire mourir le conteneur seul quand une fuite apparaît, plutôt que d’entraîner tout le serveur.

Pourquoi un conteneur peut-il faire tomber le serveur ?

Docker a une « particularité » : par défaut, les conteneurs n’ont aucune limite de ressources. Ça semble libérateur, non ? Assez libre pour qu’un conteneur consomme toute la mémoire et le CPU de l’hôte — et que tout le monde y passe.

Cas réel avec Docker 27.4.0 : un utilisateur a constaté que dockerd passait de quelques centaines de Mo à 8 Go en quelques jours, rendant le serveur très lent. Ce n’est pas Docker qui est instable — si vous ne fixez pas de limites, le conteneur galope comme un cheval sans bride.

Le noyau Linux active alors un mécanisme « tueur » — l’OOM Killer (Out Of Memory Killer). Quand la mémoire manque, il choisit le processus « le plus approprié » à tuer. Comment ? Chaque processus reçoit un score (oom_score) ; plus il est élevé, plus le risque est grand. Les processus dans les conteneurs ont souvent un score élevé, mais le daemon Docker est plus malin : il abaisse sa priorité OOM (oom_score_adj à -500), donc ce sont vos conteneurs qui prennent le coup.

Dans docker ps, le conteneur a disparu ; les logs montrent Exit Code 137. Signification : 128 + 9 (signal SIGKILL) — « tué de force ». Pas une sortie propre, une exécution par le noyau.

Symptômes typiques d’une fuite mémoire :

• La mémoire du conteneur monte en flèche, de quelques centaines de Mo à plusieurs Go
• Le serveur swappe frénétiquement, le disque clignote
• Les autres conteneurs ralentissent puis tombent
• Vos graphiques de monitoring dessinent une belle droite montante

En 2024, un cas de la communauté Storj était extrême : un conteneur est passé de quelques centaines de Mo à 37 Go, menaçant tout le nœud de stockage. Avec une limite mémoire à 1 Go, l’OOM Killer aurait stoppé le conteneur bien avant — le serveur serait resté stable.

[Image : courbe de fuite mémoire]
Prompt : server memory usage graph showing sharp upward spike, red critical zone at 90%, dark background, monitoring dashboard style, high quality

cgroups : le principe sous-jacent des limites

Vous avez entendu parler des cgroups pour les limites Docker — qu’est-ce que c’est ? En bref, cgroups (Control Groups) est une fonctionnalité du noyau Linux qui fixe des quotas par groupe de processus — comme une « carte ressources » : une fois le plafond atteint, plus de dépassement.

Docker crée un cgroup à la création du conteneur et y place les processus. Quand vous lancez docker run -m 512m nginx, Docker écrit dans /sys/fs/cgroup/memory/docker/<containerID>/memory.limit_in_bytes la valeur 536870912 (512 Mo en octets). Le noyau lit ce fichier : ce conteneur a 512 Mo max, au-delà il est stoppé.

cgroups v1 vs v2 :

• v1 : mémoire, CPU, I/O disque en sous-systèmes séparés, chacun gère son domaine
• v2 : gestion unifiée, hiérarchie plus claire, mieux adaptée aux conteneurs
• Anciens systèmes (RHEL 7) encore en v1 ; récents (Ubuntu 20.04+, RHEL 8+) basculent vers v2

Pour inspecter la config cgroup d’un conteneur :

# Trouver l'ID complet du conteneur
docker inspect --format='{{.Id}}' my_container

# Limite mémoire (cgroups v1)
cat /sys/fs/cgroup/memory/docker/<containerID>/memory.limit_in_bytes

# Quota CPU (cgroups v1)
cat /sys/fs/cgroup/cpu/docker/<containerID>/cpu.cfs_quota_us

La première fois que j’ai vu ces fichiers, j’étais perplexe : des limites via le système de fichiers ? C’est la philosophie Linux « everything is a file » — le noyau expose la config cgroup en fichiers, Docker écrit, le noyau applique. Élégant.

[Image : schéma hiérarchie cgroups]
Prompt : Linux cgroups hierarchy diagram, containers grouped under docker cgroup, memory and CPU subsystems, tree structure, technical illustration, clean design, high quality

Paramètres mémoire : guide complet

Les paramètres mémoire Docker sont nombreux ; en pratique, quelques-uns suffisent. Détail.

1. --memory / -m (limite dure, la plus importante)

Paramètre vital. À cette valeur, l’OOM Killer tue le conteneur. Minimum théorique 6 Mo (peu utilisable) ; en production, comptez au minimum quelques centaines de Mo.

# Limiter à 512 Mo
docker run -m 512m nginx

# Unité GB
docker run -m 2g my-app

Comment choisir ? Mon approche : stress-test en conditions normales, puis multiplier par 1,2 à 1,5. Application à 300 Mo → 400-450 Mo est raisonnable. Trop bas : OOM fréquents ; trop haut : protection affaiblie.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

2. --memory-swap (swap, souvent mal compris)

Ce paramètre fixe le total mémoire + swap, pas le swap seul.

# 512 Mo RAM + 512 Mo swap (1 Go au total)
docker run -m 512m --memory-swap 1g nginx

# Désactiver le swap (RAM seule)
docker run -m 512m --memory-swap 512m nginx

# Swap illimité (dangereux !)
docker run -m 512m --memory-swap -1 nginx

Sans --memory-swap, par défaut swap = memory : total utilisable = 2 × memory. -m 512m → jusqu’à 1 Go (512 Mo + 512 Mo swap).

Production : désactiver le swap (--memory-swap = --memory) ou limiter le swap à la moitié de la RAM. Évitez -1 : le swap excessif tue le disque.

3. --memory-reservation (limite souple)

« Plafond flexible ». Si la RAM de l’hôte est disponible, le conteneur peut dépasser ; sous pression, le noyau le ramène sous ce seuil. Doit être inférieur à --memory.

# Souple 750 Mo, dur 1 Go
docker run -m 1g --memory-reservation 750m nginx

Utile pour des pics courts (batch) avec une consommation basse au repos.

4. --kernel-memory (mémoire noyau, à manier avec prudence)

Limite la mémoire noyau (buffers réseau, cache FS) — non swappable. Sauf expertise, évitez : une mauvaise valeur empêche le démarrage.

5. --oom-kill-disable (paramètre dangereux)

Désactive l’OOM Killer : le conteneur n’est pas tué en cas de dépassement. Erreur grave. Sans kill, la fuite épuise toute la RAM du serveur.

# Dangereux ! (mémoire illimitée effective)
docker run --oom-kill-disable nginx

# Si vraiment nécessaire, toujours avec limite mémoire
docker run -m 512m --oom-kill-disable nginx

Quand l’utiliser ? Presque jamais. Sauf processus qui ne doit pas être tué brutalement (checkpoint base de données) et contrôle mémoire garanti côté application.

Cas réel : sur AWS, un conteneur sans limite a atteint 30 Go et rendu l’instance inutilisable. Après -m 2g, le conteneur meurt et redémarre à la limite — le serveur reste stable.

[Image : relation paramètres mémoire]
Prompt : Docker memory parameters diagram, showing memory and swap relationship, visual chart with bars and labels, technical illustration, blue and orange colors, high quality

Paramètres CPU : guide complet

Les limites CPU sont plus douces — pas de kill, juste un ralentissement. Mais un CPU incontrôlé peut aussi paralyser le serveur.

1. --cpus (le plus intuitif)

Nombre de cœurs CPU utilisables, décimaux acceptés.

# 1,5 cœur max
docker run --cpus="1.5" nginx

# Demi-cœur
docker run --cpus="0.5" my-app

Sous le capot, c’est --cpu-period + --cpu-quota. À 1,5, le conteneur utilise au plus 1,5 cœur à un instant — un cœur plein plus 50 % d’un autre.

2. --cpu-shares (poids relatif, pas une limite dure)

Priorité de planification CPU, défaut 1024. Ne s’applique que si le CPU est saturé. Si l’hôte est idle, le conteneur peut utiliser tout ce qu’il veut.

# A reçoit 2× le temps CPU de B
docker run --cpu-shares 2048 --name app_a my-app
docker run --cpu-shares 1024 --name app_b my-app

Sur 2 cœurs saturés, répartition ~2:1 — A ~1,33 cœur, B ~0,67. CPU libre : les deux vont à fond.

Usage : plusieurs conteneurs, prioriser un service (API vs tâches batch).

3. --cpuset-cpus (cœurs dédiés)

Épingler le conteneur sur certains cœurs uniquement.

# Cœurs 0 et 3 seulement
docker run --cpuset-cpus="0,3" nginx

# Cœurs 2 à 5
docker run --cpuset-cpus="2-5" my-app

Cas d’usage :

• NUMA : serveur multi-socket, conteneur sur un socket pour limiter l’accès mémoire inter-socket
• Cache CPU : processus fixes, meilleur taux de hit cache
• Isolation : service critique sur cœurs dédiés

Dans un cluster Kubernetes, j’ai vu une base liée aux 4 derniers cœurs d’un hôte 8 cœurs, les 4 premiers pour le web — gain notable.

4. --cpu-period et --cpu-quota (contrôle fin)

Paramètres bas niveau ; --cpus les encapsule.

• --cpu-period : période CFS, défaut 100 000 µs (100 ms)
• --cpu-quota : temps CPU max par période (µs)

# 50 ms CPU sur 100 ms (≈ 0,5 cœur)
docker run --cpu-period=100000 --cpu-quota=50000 nginx

# Équivalent à
docker run --cpus="0.5" nginx

En général --cpus suffit, sauf besoin de périodes très courtes.

Cas réel : bug avec boucle infinie dans un pool de threads, CPU à 800 % (hôte 8 cœurs). Sans limite, SSH inaccessible. Après --cpus="2" partout, le bug ne ralentit que le conteneur fautif.

[Image : comparaison limites CPU]
Prompt : CPU usage comparison chart, with and without limits, before/after graph showing CPU spike prevention, performance monitoring dashboard, clean visualization, high quality

Surveillance en conditions réelles

Fixer des limites n’est que la première étape — il faut aussi mesurer l’utilisation réelle. Attendre l’OOM pour découvrir la fuite, c’est trop tard.

Outil 1 : docker stats (intégré, coût zéro)

Le plus simple, inclus dans Docker.

# Rafraîchissement temps réel, Ctrl+C pour quitter
docker stats

# Une seule sortie, pour scripts
docker stats --no-stream

# Conteneurs spécifiques
docker stats nginx_container mysql_container

Exemple de sortie :

CONTAINER ID   NAME      CPU %     MEM USAGE / LIMIT     MEM %     NET I/O
a1b2c3d4e5f6   nginx     0.50%     45.2MiB / 512MiB     8.83%     1.2kB / 0B

Avantages : prêt à l’emploi.
Inconvénients : pas d’historique, pas d’alerte, pas de visualisation riche. Bon pour le dépannage ponctuel, pas la surveillance long terme.

Outil 2 : cAdvisor (Google, spécialiste conteneurs)

cAdvisor (Container Advisor) détecte tous les conteneurs de l’hôte, collecte CPU, mémoire, réseau, I/O disque, avec interface web et export Prometheus.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Lancement simple :

docker run -d \
  --name=cadvisor \
  --restart=always \
  -p 8080:8080 \
  -v /:/rootfs:ro \
  -v /var/run:/var/run:ro \
  -v /sys:/sys:ro \
  -v /var/lib/docker/:/var/lib/docker:ro \
  -v /dev/disk/:/dev/disk:ro \
  gcr.io/cadvisor/cadvisor:latest

http://IP_SERVEUR:8080 pour les tendances ; http://IP_SERVEUR:8080/metrics pour Prometheus.

Avantages : complet, écosystème Prometheus.
Inconvénients : ~2 minutes d’historique seulement — Prometheus pour la rétention longue.

Outil 3 : Prometheus + Grafana (niveau entreprise)

Stack complète :

• cAdvisor : collecte
• Prometheus : stockage
• Grafana : visualisation + alertes

docker-compose.yml complet :

version: '3.8'

services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    container_name: cadvisor
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
      - /dev/disk/:/dev/disk:ro
    restart: always

  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
    restart: always

  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin
    restart: always

volumes:
  prometheus_data:
  grafana_data:

prometheus.yml associé :

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

Après déploiement :

1. Prometheus scrape cAdvisor toutes les 15 s
2. Grafana sur http://IP_SERVEUR:3000 (admin/admin par défaut)
3. Ajouter Prometheus comme source (http://prometheus:9090)
4. Importer un dashboard (ID recommandé : 19908, dédié Docker)

Métriques clés :

• container_memory_usage_bytes : mémoire actuelle
• container_memory_max_usage_bytes : pic historique
• container_cpu_load_average_10s : charge CPU 10 s
• container_fs_io_time_seconds_total : temps I/O disque

Alerte à 80 % de mémoire par e-mail ou Slack — vous attrapez le problème avant l’explosion.

Franchement, la mise en place demande un effort, mais c’est durable. Mes 20+ conteneurs sont sous Grafana — plus de réveil nocturne.

[Image : dashboard Grafana conteneurs]
Prompt : Grafana dashboard showing Docker container metrics, memory and CPU graphs, clean modern UI, dark theme, monitoring panels with colorful charts, high quality

Flux complet de diagnostic d’une fuite mémoire

Alerte ou conteneur mort sans raison apparente ? Suivez ce flux.

Étape 1 : détecter l’anomalie

docker stats pour voir quel conteneur gonfle :

docker stats --no-stream | grep -v "0.00%"

Mémoire proche de la limite ? Vérifier un OOM récent :

# Événements OOM
docker events --filter 'event=oom' --since '24h'

# Code de sortie
docker inspect <nom_conteneur> --format='{{.State.ExitCode}}'
# 137 = tué par l'OOM Killer

Étape 2 : analyser la consommation

Entrer dans le conteneur pour identifier le processus :

# Entrer dans le conteneur
docker exec -it <nom_conteneur> /bin/bash

# Classement par mémoire (top/htop requis)
top -o %MEM

# Ou ps
ps aux --sort=-%mem | head -n 10

Application Java : exporter un heap dump :

# PID Java
jps

# Heap dump
jcmd <PID> GC.heap_dump /tmp/heap.hprof

# Copier pour analyse
docker cp <nom_conteneur>:/tmp/heap.hprof ./

Étape 3 : mesures d’urgence

Le service est impacté — soulagement temporaire :

# Redémarrer (perte des données temporaires du conteneur)
docker restart <nom_conteneur>

# Ajuster la limite à chaud
docker update --memory 1g --memory-swap 1g <nom_conteneur>

# Nettoyer les ressources inutilisées (attention : supprime images/conteneurs non utilisés)
docker system prune -a

Étape 4 : correction durable

Les mesures d’urgence ne suffisent pas :

1. Corriger le code : connexions non fermées, cache sans borne, gros objets non libérés
2. Limites : si absentes, ajouter --memory immédiatement
3. Surveillance : Prometheus + Grafana pour alerter avant la crise
4. Redémarrage auto : --restart=on-failure:3, max 3 redémarrages après OOM

Aide-mémoire commandes :

# Limites de tous les conteneurs
docker ps --format "{{.Names}}" | xargs docker inspect \
  --format='{{.Name}}: Memory={{.HostConfig.Memory}} CPU={{.HostConfig.NanoCpus}}'

# Nombre de redémarrages
docker inspect --format='{{.RestartCount}}' <nom_conteneur>

# Logs (100 dernières lignes)
docker logs --tail 100 <nom_conteneur>

# Détail mémoire
docker stats --no-stream --format \
  "table {{.Name}}\t{{.MemUsage}}\t{{.MemPerc}}" <nom_conteneur>

Retour sur le cas Storj (37 Go) :

1. docker restart pour restaurer le service
2. -m 1g pour protéger l’hôte
3. Logs + heap dump à l’équipe dev
4. Mise à jour image après correctif
5. cAdvisor + alerte à 70 % mémoire

Pénible sur le moment, mais plus de récidive depuis.

[Image : fluxogramme diagnostic mémoire]
Prompt : flowchart showing memory leak diagnosis process, step by step from detection to resolution, arrows connecting boxes, clean infographic style, blue and green colors, high quality

Bonnes pratiques et pièges à éviter

Récapitulons l’usage en production.

Checklist production

✅ Limite mémoire sur tous les conteneurs
Même un Nginx statique : 512 Mo minimum. Mieux vaut être conservateur que réparer après coup.

✅ Dev proche de la prod
Ne pas lancer sans limites en local pour découvrir le problème en prod. Visez ~80 % des limites de production en dev.

✅ Audit régulier
Chaque mois, docker stats — ajuster si les besoins ont changé.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

❌ Ne pas désactiver l’OOM Killer
Sauf certitude absolue sur le contrôle mémoire de l’app, évitez --oom-kill-disable. Paramètre suicidaire.

❌ Pas de swap illimité
--memory-swap -1 est un piège : le disque meurt avant que le conteneur ne soit tué proprement.

❌ Limite trop basse
OOM fréquents = disponibilité en chute. Stress-test d’abord, limites ensuite.

Docker Compose : la bonne forme

services:
  web:
    image: nginx:latest
    deploy:
      resources:
        limits:
          cpus: '1.5'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 256M
    restart: on-failure:3

Champ deploy (Compose v3). limits = dur, reservations = souple. 256 Mo au repos, jusqu’à 512 Mo en charge.

Gérer plusieurs conteneurs en lot

Pour un pool de microservices, cgroup-parent :

# Groupe parent avec plafond global
docker run --cgroup-parent=/my-services -m 2g service-a
docker run --cgroup-parent=/my-services -m 2g service-b
# Les deux partagent le cgroup parent

Utile quand plusieurs conteneurs forment une unité métier à limiter globalement.

Formules empiriques

Estimations conservatrices — adaptez au trafic. Pic observé × 1,5 pour la limite est un bon point de départ.

Comparaison avec Kubernetes

Sur Kubernetes, requests et limits ressemblent aux paramètres Docker :

• requests ≈ --memory-reservation
• limits ≈ --memory

K8s centralise la config YAML ; Docker reste plus flexible (docker update à chaud).

Dernier conseil

Les limites ne sont pas « une fois pour toutes ». L’application évolue, le trafic aussi — les métriques indiquent s’il faut augmenter ou optimiser. Revoyez la config régulièrement.

[Image : tableau comparatif bonnes pratiques]
Prompt : comparison table showing Docker resource limits best practices, checkmarks and crosses, clean infographic style, professional layout, high quality

Conclusion

Retour au récit du début : réveil à 3 h du matin, serveur à terre à cause d’un conteneur. Cette leçon m’a appris que la « liberté » par défaut de Docker est un piège. Sans limites explicites, vous confiez le sort du serveur aux conteneurs.

La défense en trois lignes :

Première ligne : limites (prévention)
--memory et --cpus sur chaque conteneur — la bride sur le cheval sauvage. En cas de dérapage, le conteneur meurt seul. Étape de base et indispensable.

Deuxième ligne : surveillance (détection)
docker stats pour l’instant présent ; cAdvisor + Prometheus + Grafana pour tendances et historique. Alerte à 80 % mémoire — signaux 48 h avant la catastrophe.

Troisième ligne : diagnostic (réaction)
En cas de problème : détecter → analyser → urgence → correction. Les commandes sont dans l’article.

Des cgroups aux détails de --memory-swap, du Compose au parallèle Kubernetes — vous avez l’essentiel. Il reste l’action.

Trois actions maintenant :

1. Auditez la production — conteneurs sans limite :

docker ps --format "{{.Names}}" | xargs docker inspect \
  --format='{{.Name}}: Memory={{.HostConfig.Memory}} CPU={{.HostConfig.NanoCpus}}'

Memory=0 = bombe à retardement.

2. Déployez la surveillance — copiez le docker-compose.yml de l’article, 30 minutes.

3. Rappel mensuel — 1 h avec docker stats pour vérifier l’utilisation.

Je ne souhaite pas que vous appreniez comme moi à 3 h du matin. Configurez les limites tôt — vous gagnerez en sérénité.