TL;DR : avant d’acheter de la mémoire, arrêtez les services que vous n’ouvrez jamais. Sur la plupart des serveurs maison, ça libère plus que la barrette qu’on s’apprêtait à commander.
Vous montez un serveur à la maison, vous suivez notre guide pour démarrer, et tout va bien. Puis vous testez un service, puis un autre, puis ce truc formidable vu sur un forum. Six mois plus tard, la machine rame, et le premier réflexe est de regarder le prix des barrettes de mémoire.
Mauvais réflexe. Comptez d’abord combien de vos conteneurs vous avez ouverts cette semaine.
Ce que coûte vraiment un conteneur qui ne fait rien
Un conteneur arrêté ne consomme ni processeur, ni mémoire vive. Il occupe de l’espace disque, pour son image et ses volumes, et c’est tout. Rien ne tourne.
Un conteneur démarré mais inutilisé, c’est autre chose. Ses processus restent en mémoire, et beaucoup de services ne se contentent pas d’attendre : ils indexent une bibliothèque, interrogent une API, tournent un ramasse-miettes, vérifient leur propre santé toutes les trente secondes. Vous ne les regardez pas, ils travaillent quand même.
C’est la mémoire vive qui part en premier sur une petite machine, bien avant le processeur. Et c’est exactement là que dorment les services que vous avez installés « pour voir ».
La commande qui met fin au débat
Avant de trier, mesurez :
docker stats --no-stream --format "table {{.Name}}\t{{.MemUsage}}\t{{.CPUPerc}}"Vous obtenez, en une ligne par conteneur, la mémoire occupée et le processeur consommé à l’instant T. Lancez-la trois fois dans la journée, dont une la nuit. Les surprises se voient tout de suite : ce sont rarement les services auxquels on pense.
Je ne vous donne pas de chiffres tout faits, parce qu’ils ne veulent rien dire. La même application consomme du simple au triple selon la taille de votre bibliothèque et vos réglages. Mesurez la vôtre, ça prend trente secondes.
Trois familles, et une seule question par famille
1. Ce qui doit tourner, sans discussion
La question : est-ce que quelque chose d’autre en dépend, ou est-ce qu’il doit recevoir quelque chose sans prévenir ?
Y entrent le reverse proxy, le serveur DNS, le réseau privé qui vous donne accès à distance, la supervision, la base de données partagée, la domotique, et tout ce qui doit encaisser une connexion entrante à n’importe quelle heure. Un service qui reçoit une alerte, une notification ou une sauvegarde venue de l’extérieur ne se met jamais en veille : endormi, il ne rate pas la requête, il la perd.
Pour ceux-là, une seule politique de redémarrage :
restart: unless-stoppedElle relance le conteneur après un plantage ou un redémarrage de la machine, mais respecte votre décision quand vous l’avez arrêté à la main. C’est la différence avec always, qui le fait revenir au prochain démarrage du démon même si vous l’aviez volontairement coupé. Sur un serveur qu’on bricole, cette nuance évite beaucoup d’énervement.
2. Ce qu’on réveille quand on en a besoin
La question : est-ce que j’ouvre ça dans un navigateur, quelques fois par mois ?
Les interfaces d’administration, les outils de conversion, les éditeurs en ligne, les bacs à sable, tout ce que vous avez installé pour essayer. Aucun n’a besoin d’être debout en permanence.
La solution paresseuse marche très bien : docker compose up -d quand vous en avez besoin. Mais il y a mieux, et c’est Sablier. Placé derrière votre reverse proxy, il intercepte la requête, démarre le conteneur, affiche une page d’attente le temps du démarrage, puis arrête le service tout seul après une période d’inactivité que vous choisissez.
Il fonctionne avec Traefik, Caddy, Nginx, Envoy, APISIX et Istio, et pilote Docker, Docker Compose, Swarm, Podman, Kubernetes ou des conteneurs LXC sur Proxmox. Le projet est sous licence AGPL, actif, et annonce environ 1,5 à 2 millisecondes de latence ajoutée en régime normal. Autrement dit : rien, sauf au réveil.
Le détail qui fait sourire : le thème par défaut de la page d’attente s’appelle hacker-terminal.
3. Ce qui n’a besoin que de quelques minutes par jour
La question : est-ce que ça a un début et une fin ?
Les sauvegardes, les synchronisations, les récupérations de flux, les rapports. Ces services n’ont aucune raison d’occuper la mémoire vingt-quatre heures pour travailler cinq minutes. Un minuteur systemd ou une ligne de cron les lance à l’heure dite :
30 3 * * * cd /srv/sauvegarde && docker compose run --rm sauvegarderun --rm fait le travail puis efface le conteneur. Rien ne reste debout.
Le piège, et il est sérieux
Ne mettez jamais en veille ce qui doit recevoir quelque chose. Un service de sauvegarde qui attend un envoi depuis un autre appareil, un récepteur de notifications, un serveur de messagerie, un pont domotique : endormis, ils ne se réveillent pas à la demande, parce que la demande n’arrive jamais jusqu’à eux.
Sablier ne sauve que ce qui passe par le reverse proxy, c’est-à-dire du trafic web que vous déclenchez vous-même. Tout le reste doit rester debout.
Mon avis
J’ai fait le tri sur ma propre machine avant d’écrire ces lignes, et le résultat est banal : la moitié des conteneurs n’avaient pas été ouverts depuis des semaines. Pas de miracle, pas de réglage exotique, juste un inventaire que personne ne fait jamais parce qu’installer est amusant et ranger ne l’est pas.
La vraie question n’est pas « combien de mémoire me faut-il », c’est « qu’est-ce que j’utilise vraiment ». Elle est désagréable, et elle coûte moins cher qu’une barrette.
