Mémoire et CPU des applications Docker sur macOS : mesures

Ce que nous avons mesuré, et comment

Les trois applications ont tourné sur un même Mac : un Apple M5 Max avec 36 GiB de mémoire et macOS 27.2. Chacune était réglée sur 8 CPU et 12 GiB, redémarrée avec sa propre commande et exécutée seule, les autres étant fermées et leur arrêt vérifié. Les valeurs au repos proviennent d’une fenêtre de 60 secondes après 45 secondes de stabilisation et comptent tous les processus du produit : l’application, ses auxiliaires et le moteur avec son système Linux. Les valeurs des conteneurs sont les médianes de cinq échantillons après une phase de chauffe ; tout écart inférieur ou égal à 10 % est considéré comme équivalent.

Oxcart 0.1.2 a été mesuré le 2026-10-10 avec son client docker 29.9 intégré. OrbStack 2.2.3 et Docker Desktop 4.94.0 ont été mesurés plus tôt le même jour, sur le même Mac avec le même dispositif de mesure et docker 29.4. Chaque produit utilise son propre noyau Linux. Il s’agit d’un passage par produit sur une seule machine, pas d’une étude ; la méthode est identique pour tous.

Mémoire au repos sans conteneur

C’est la mémoire qu’une application de conteneurs consomme simplement pour être prête : entre deux sessions de travail, pendant une réunion ou sur un portable où elle reste ouverte toute la journée. Oxcart et OrbStack sont au même niveau ; Docker Desktop en conserve plus du double.

Le coût de la surveillance des conteneurs

Les tableaux de bord, les outils de suivi dans le terminal et les agents de programmation interrogent constamment les statistiques des conteneurs : leur consultation coûte donc plus qu’il n’y paraît.

CPU en pourcentage d’un cœur. Oxcart 0.1.2 mesuré le 2026-10-10 avec son client docker 29.9 intégré ; OrbStack 2.2.3 et Docker Desktop 4.94.0 mesurés plus tôt le même jour, sur le même Mac avec le même dispositif et docker 29.4.

Avec 20 conteneurs en cours d’exécution, l’élément d’Oxcart dans la barre des menus consomme 0,0004 % d’un cœur et provoque 0,033 réveil par seconde. Ce chiffre concerne uniquement l’application, pas le moteur.

En charge : à égalité

Dès que les conteneurs travaillent vraiment, les applications se rapprochent, car le travail lui-même domine. Deux lignes du même passage :

En pratique : une compilation ou un test limité par le CPU coûte à peu près autant de CPU sur le Mac dans les trois applications, et un conteneur utilisant 256 MiB coûte environ autant à votre Mac. Les différences se trouvent autour du travail : la durée de chaque docker run, stop et nettoyage, où Oxcart prend l’avantage (face à Docker Desktop, face à OrbStack).

Après le travail : la mémoire revient à macOS

Depuis Oxcart 0.1.3, environ 30 s après l’arrêt de votre dernier conteneur, Oxcart redémarre sa partie Linux et rend la mémoire à macOS : 570 MiB au lieu de 3319 MiB, 32 s après l’arrêt du dernier conteneur (deuxième passage : de 3352 à 579 MiB). Cela ne se produit que si aucun conteneur ne tourne. Le redémarrage se fait en arrière-plan : une commande Docker arrivant pendant ce temps attend simplement sa fin.

Mesuré sur Oxcart 0.1.3.

Mesurer la mémoire d’une application de conteneurs sur votre Mac

1. Commencez avec un Mac au calme. Fermez les autres applications de conteneurs, arrêtez vos conteneurs et attendez une minute après le lancement de l’application pour laisser le démarrage se terminer.
2. Trouvez tous les processus de l’application. Dans Moniteur d’activité, ouvrez l’onglet Mémoire et recherchez le nom de l’application ; le processus qui exécute la partie Linux est généralement le plus gros. Dans le terminal, ps -axo pid,rss,comm | grep -i <app> les affiche.
3. Lisez la mémoire comptabilisée par macOS. Utilisez la colonne Mémoire de Moniteur d’activité ou footprint <pid> pour chaque processus, puis additionnez les valeurs. La taille résidente (RSS) seule peut surestimer ou sous-estimer la mémoire partagée et compressée.
4. Mesurez pendant votre travail. Démarrez votre stack Compose habituelle, utilisez-la quelques minutes, puis relevez de nouveau les mêmes valeurs. docker stats --no-stream indique ce que chaque conteneur utilise dans la partie Linux.
5. Mesurez après l’arrêt. Arrêtez tout et relevez encore les valeurs une minute plus tard. C’est la mémoire que l’application conserve au repos entre deux sessions de travail.

Les réglages qui comptent

• Limites de l’application. Chaque application plafonne les CPU et la mémoire de sa partie Linux. Dans Oxcart : Settings › Resources, ou oxcart config set cpus=6 et oxcart config get ; les valeurs s’appliquent au prochain démarrage. Un plafond bien supérieur aux besoins de votre stack n’apporte rien.
• Limites par conteneur. --memory, --cpus et --pids-limit avec docker run, ou mem_limit, cpus et pids_limit dans Compose, empêchent un service qui s’emballe de tout accaparer.
• Arrêtez ce que vous n’utilisez pas. docker compose stop pour les stacks que vous reprendrez ; docker compose down pour les autres. Avec Oxcart, l’arrêt du dernier conteneur permet aussi de rendre la mémoire à macOS.
• Surveillez à moindre coût. Préférez docker stats --no-stream dans les scripts et donnez aux agents de programmation un outil de synthèse plutôt que des statistiques brutes (Docker pour les agents de programmation IA).

Questions

Quelle quantité de mémoire Docker utilise-t-il sur Mac ?

Cela dépend de l’application et du travail de vos conteneurs. Sans conteneur en cours d’exécution, sur un Mac à puce Apple réglé sur 12 GiB, nous avons mesuré 776 MiB pour Oxcart, 792 MiB pour OrbStack et 1745 MiB pour Docker Desktop, en comptant tous les processus de chaque produit. Dès que les conteneurs tournent, la mémoire suit leurs charges de travail.

Pourquoi Docker Desktop utilise-t-il autant de mémoire ?

Toute application de conteneurs sur Mac exécute un système Linux, et la mémoire à laquelle ses charges de travail accèdent apparaît comme un gros processus sur le Mac. Dans nos mesures, Docker Desktop avait aussi la plus forte consommation au repos des trois : 1745 MiB sans conteneur. Réduisez sa limite mémoire dans les réglages, arrêtez les conteneurs inutiles et comparez une alternative comme Oxcart, qui utilisait 776 MiB au repos sur le même Mac.

Oxcart rend-il la mémoire à macOS ?

Oui, dès que plus rien ne tourne. Depuis Oxcart 0.1.3, environ 30 s après l’arrêt de votre dernier conteneur, Oxcart redémarre sa partie Linux et rend la mémoire à macOS : 570 MiB au lieu de 3319 MiB, 32 s après l’arrêt du dernier conteneur, lors d’une mesure sur une version préliminaire. Cela ne se produit que si aucun conteneur ne tourne.

Comment limiter la mémoire et le CPU d’un conteneur ?

Par conteneur : docker run --memory 512m --cpus 1.5 …, ou mem_limit et cpus dans un service Compose. Oxcart applique les changements de limites de mémoire, de CPU et de nombre de processus avec docker update, et les conserve même si un redémarrage recrée le conteneur.

Comment définir les CPU et la mémoire qu’Oxcart peut utiliser ?

Dans Settings › Resources, ou dans le terminal avec oxcart config set cpus=4 et oxcart config get pour voir les valeurs effectives et les limites de votre Mac. Les nouvelles valeurs s’appliquent au prochain démarrage.

docker stats ralentit-il mon Mac ?

Un flux docker stats consomme du CPU dans chaque application. Nous avons mesuré 1,3 % d’un cœur pour Oxcart, 3,8 % pour OrbStack et 5,5 % pour Docker Desktop ; Oxcart était le moins coûteux. Un appel unique à docker stats --no-stream pour 20 conteneurs prenait 1,0 s sur Oxcart, environ moitié moins que sur les deux autres.

Sources et méthode

• Oxcart 0.1.2, OrbStack 2.2.3 et Docker Desktop 4.94.0, mesurés le 2026-10-10 sur le même Mac (Apple M5 Max, 36 GiB, macOS 27.2), avec 8 CPU et 12 GiB chacun, un seul produit à la fois.
• Mémoire rendue après l’arrêt du dernier conteneur : Oxcart 0.1.3.
• Coût de la barre des menus : mesuré sur Oxcart le 2026-10-09.