WSL2 Limites mémoire/CPU : Empêchez-le de manger votre RAM

Comment WSL2 utilise réellement la mémoire et le CPU

WSL2 n’est pas « Linux qui tourne dans une couche de compatibilité ». C’était plutôt WSL1. WSL2 exécute un vrai noyau Linux à l’intérieur d’une machine virtuelle légère gérée par Hyper-V. C’est pourquoi WSL2 offre une meilleure compatibilité des appels système et pourquoi il peut aussi vous manger de la RAM.

Le modèle mental qui ne vous trahira pas

• Windows possède le matériel. WSL2 est une VM invitée. L’invité peut demander de la mémoire et du CPU ; l’hôte l’alloue et planifie.
• La mémoire WSL2 est « élastique » jusqu’à ce qu’elle ne le soit plus. La VM peut gonfler quand Linux met en cache des données de fichiers, alloue de la mémoire pour des builds, ou exécute des conteneurs.
• Linux utilise la RAM libre pour le cache. C’est normal. Le mode défaillant survient quand ce cache ne revient pas assez vite à Windows, ou quand la VM atteint une limite et commence à swapper.
• vmmem est la facture. Le Gestionnaire des tâches n’affiche pas la « mémoire du processus WSL2 » comme vous l’espérez ; il montre le processus conteneur de la VM. Cela inclut le noyau Linux, le cache de pages et tout ce que vous avez lancé dans WSL2.

Le CPU est plus simple : sans limites, WSL2 peut utiliser autant de cœurs que Windows voudra en planifier. Si vous avez déjà vu un build Rust ou un make -j parallèle anéantir l’interactivité, vous avez vu la politique par défaut : « Félicitations, vous avez acheté des cœurs ; nous allons tous les utiliser. »

Une pensée pour vous garder honnête, idée paraphrasée de Gene Kim (auteur fiabilité/ops) : idée paraphrasée : un flux rapide et des systèmes stables viennent de la réduction du travail en cours et de la limitation du rayon d’explosion. Les limites de ressources sont littéralement du contrôle du rayon d’explosion.

Petite blague n°1 : WSL2 ne « fuit » pas la mémoire. Il l’adopte définitivement et la nomme d’après votre répertoire de build.

Faits intéressants et contexte historique (les parties qu’on n’entend pas en standup)

1. WSL1 vs WSL2 fut un pivot philosophique. WSL1 traduisait les appels système Linux vers Windows. WSL2 embarque un vrai noyau Linux, ce qui a corrigé la compatibilité mais réintroduit le comportement de type VM en matière de ressources.
2. Le processus vmmem est un conteneur Hyper-V. C’est la représentation côté hôte de la VM WSL2. C’est pourquoi il paraît « mystérieux » dans le Gestionnaire des tâches et pourquoi tuer des processus Linux au hasard ne le réduira pas forcément rapidement.
3. Le cache de pages Linux n’est pas de la RAM « gaspillée ». C’est une optimisation de performance. Quand ça devient un problème, le problème porte sur la récupération à travers la frontière VM/hôte, pas sur la « gourmandise » de Linux.
4. Le ballooning mémoire est une technique VM connue. Les hyperviseurs peuvent récupérer la mémoire invitée avec des pilotes balloon. Le comportement de WSL2 s’est amélioré avec le temps, mais ce n’est pas magique ni instantané.
5. WSL2 a eu une histoire de « mémoire qui ne revient pas ». Les premières versions en étaient notoirement victimes. Les versions récentes de Windows 11 et les mises à jour WSL ont amélioré la récupération, notamment avec des fonctionnalités comme le page reporting.
6. Le backend WSL2 de Docker a changé la donne. Plutôt qu’une lourde VM LinuxKit, Docker Desktop peut tourner dans WSL2, ce qui fait de la politique de ressources WSL2 le problème de tout le monde, pas seulement des développeurs Linux.
7. Le swap dans WSL2 n’est pas le pagefile Windows. WSL2 peut avoir son propre fichier de swap. Vous pouvez le régler, et vous devriez, car le « swap surprise » est la raison pour laquelle les portables se mettent à ressembler à des tas de gravier en traitement.
8. Le support systemd dans WSL2 a été un grand changement. Plus de services d’arrière-plan peuvent tourner, ce qui est excellent pour le réalisme et aussi excellent pour consommer silencieusement RAM et CPU si vous traitez WSL comme un shell jetable.
9. Les limites CPU sont rustres mais efficaces. La VM n’est pas un sandbox cgroup par défaut. Si vous voulez que « les charges de travail Linux ne volent pas l’interactivité Windows », les plafonds CPU au niveau VM sont un marteau étonnamment propre.

Plan de diagnostic rapide

Quand la machine semble lente, ne commencez pas par éditer des fichiers de config. D’abord, déterminez quel type de lenteur vous affrontez. Il y a trois goulots courants : pression mémoire hôte, pression mémoire invitée et contention CPU. Le disque est le quatrième, plus sournois.

Première étape : est-ce que Windows suffoque à cause de la RAM ou du CPU ?

• Vérifiez le Gestionnaire des tâches : graphe mémoire, graphe CPU, et quels processus sont en tête (vmmem vs les autres).
• Décision : Si Windows swappe beaucoup ou que la mémoire est >90% utilisée, traitez cela comme une urgence mémoire hôte. Si le CPU est saturé, traitez-le comme un problème d’ordonnancement/contention.

Deuxième étape : WSL2 est-il le coupable ou juste à proximité ?

• Vérifiez les distributions WSL : voyez ce qui tourne et si une pile de conteneurs est impliquée (Docker Desktop, Kubernetes, jobs de build).
• Décision : Si vmmem est énorme et croît, confirmez ce qui, à l’intérieur de Linux, consomme la mémoire (RSS) vs le cache. Si le CPU est élevé, confirmez s’il s’agit de compilations, de conteneurs ou de services d’arrière-plan.

Troisième étape : la mémoire est-elle « coincée » ou réellement utilisée ?

• Dans WSL : regardez free -h, ps et /proc/meminfo pour séparer la mémoire anonyme (apps) du page cache.
• Décision : Si c’est principalement du cache et que Windows souffre, vous avez besoin de limites ou d’une stratégie de récupération/arrêt forcé. Si c’est de la vraie mémoire de processus, corrigez la charge ou acceptez-la et plafonnez-la.

Quatrième étape : vérifiez le thrashing disque (parce que swap et I/O mentent)

• Dans WSL : si le swap est actif et que l’I/O wait est élevé, votre « problème mémoire » est devenu un problème disque.
• Décision : Réduisez l’usage mémoire, augmentez l’allocation de RAM (contre-intuitif mais parfois juste), ou réglez le swap pour éviter un thrash catastrophique.

Imposer des limites strictes avec .wslconfig (et ce que chaque réglage fait vraiment)

Si vous utilisez WSL2 comme un service de production — et vous devriez, parce qu’il se comporte comme tel — alors vous définissez des budgets. Les budgets protègent l’hôte. Ils vous forcent aussi à remarquer quand les charges dépassent ce qu’un portable est censé faire.

Où vit la config et comment elle s’applique

.wslconfig est lu par WSL côté Windows. Il est situé dans le répertoire de votre profil utilisateur Windows (typiquement C:\Users\<you>\.wslconfig). Il s’applique globalement aux VMs WSL2, pas par distribution.

Après l’édition, il faut généralement arrêter WSL pour que les nouveaux paramètres prennent effet. « Redémarrer le terminal » n’est pas un redémarrage. WSL est plus sournois que ça.

Paramètres de base opinionés

Sur un portable dev typique de 16 Go, j’aime donner à WSL2 assez de marge pour être rapide sans lui permettre de devenir le système d’exploitation. Un point de départ raisonnable :

cr0x@server:~$ cat /mnt/c/Users/$USER/.wslconfig
[wsl2]
memory=8GB
processors=4
swap=4GB
swapFile=C:\\Users\\%USERNAME%\\AppData\\Local\\Temp\\wsl-swap.vhdx
localhostForwarding=true

Ce que chaque ligne signifie en pratique :

• memory=8GB : plafond strict sur la mémoire de la VM. Si l’invité veut plus, il libérera le cache, puis swappera, puis souffrira. Cela protège Windows.
• processors=4 : nombre maximum de vCPU. Cela ne « pinde » pas les CPUs ; ça limite le parallélisme. Cela protège la réactivité lors des builds et des tempêtes de conteneurs.
• swap=4GB : taille du swap WSL2. Ce n’est pas une fonctionnalité de performance ; c’est un tampon d’échec. Trop petit et vous OOM. Trop grand et vous pouvez thrash silencieusement.
• swapFile=... : emplacement du swap. Mettez-le sur un stockage rapide. Ne le placez pas sur des profils réseau, des dossiers chiffrés aux politiques bizarres, ou partout où la DLP d’entreprise va vous causer des ennuis.
• localhostForwarding=true : garde le réseau sain. Ce n’est pas un réglage de ressources, mais les gens le cassent et diagnostiquent ensuite à tort une « lenteur » qui est en fait DNS ou redirection de ports.

Choisir des limites qui ne vous saboteront pas

Il n’y a pas de chiffre universellement « meilleur ». Il existe, toutefois, un mode d’échec universel : fixer des limites si basses que l’invité swappe constamment, puis accuser WSL2 d’être lent. C’est comme mettre un limiteur sur une voiture à 30 km/h et se plaindre que l’autoroute est stressante.

Utilisez ces règles empiriques :

• Mémoire : Si l’hôte a 16 Go, réglez WSL2 entre 6 et 10 Go selon ce que vous exécutez sur Windows. Si vous avez des IDE lourds sur Windows, baissez.
• CPU : Limitez à la moitié de vos cœurs pour les machines développeur. Si vous avez 12–16 cœurs, donnez 6–8 à WSL2. Si vous avez 4 cœurs, donnez-lui 2 et acceptez la réalité.
• Swap : 2–8 Go est courant. Si vous compilez de gros projets ou exécutez Kubernetes, visez le haut. Si vous tenez à la latence interactive, visez le bas et corrigez l’usage mémoire.

Petite blague n°2 : Le swap c’est comme la caféine : un peu vous maintient en vie, trop vous rend nerveux et désagréable.

Récupération de mémoire : pourquoi « ça devrait libérer la RAM » n’est pas un plan

La plainte la plus courante : « J’ai tout fermé dans Linux, mais Windows affiche toujours vmmem utilisant 10 Go. » Parfois c’est un bug. Souvent c’est juste de la physique : l’invité a utilisé de la mémoire pour le cache, et l’hôte ne la récupère pas immédiatement.

Ce qui se passe généralement

• Linux a mis en cache des données de fichiers. Les builds, installations de paquets et pulls d’images de conteneurs remplissent le page cache.
• L’invité est inactif mais garde des pages. Ces pages sont « récupérables » côté Linux, mais l’hôte ne force pas forcément la récupération tant qu’il n’y a pas de pression.
• Windows voit l’allocation VM, pas le « libre » Linux. Vous voyez donc un grand nombre et supposez que c’est de l’utilisation active.

Ce que vous pouvez faire

Il y a trois niveaux de réponse, du moins au plus perturbateur :

1. Ne rien faire tant que l’hôte n’en a pas besoin. Si Windows a suffisamment de mémoire libre et que vous ne swappez pas, n’optimisez pas à la volée.
2. Appliquer des plafonds raisonnables. C’est la solution long terme : WSL2 ne peut pas gonfler au-delà d’un budget.
3. Redémarrer WSL quand vous avez fini un travail lourd. C’est le bouton pragmatique « tout libérer maintenant ». Ce n’est pas élégant. C’est efficace.

Autre chose : si vous atteignez constamment le plafond, ce n’est pas que WSL2 se comporte mal. C’est que votre charge demande plus de RAM que votre machine ne peut en fournir confortablement. Soit augmentez les limites, réduisez le parallélisme, soit arrêtez de faire croire qu’un portable est une ferme de build.

Swap, stockage et la lente mort de votre SSD

Le swap n’est pas gratuit. C’est de la douleur différée. Sur les machines développeur, le swap apparaît pendant les « pics de chaos » : compilations parallèles, quelques conteneurs, onglets de navigateur qui se reproduisent en arrière-plan, et quelqu’un qui ouvre innocemment Teams.

Pourquoi le swap est particulièrement sournois dans WSL2

• Vous pouvez avoir un swap à l’intérieur de l’invité (le fichier de swap de WSL2) pendant que Windows a son propre pagefile. Sous pression, vous pouvez vous retrouver à paginer deux fois : Windows pagine le store backing de la VM pendant que Linux swappe à l’intérieur. C’est aussi amusant que ça en a l’air.
• Le I/O wait devient votre vrai goulot. Les graphes CPU peuvent sembler « corrects », mais tout se fige parce que vous attendez le disque.
• La taille du swap interagit avec les limites. Un plafond mémoire serré plus un swap grand peuvent maintenir une charge traînante au lieu d’échouer rapidement. C’est soit « productif », soit « souffrance prolongée », selon vos deadlines.

L’emplacement du stockage compte

WSL2 utilise un disque virtuel (VHDX) pour chaque distribution. Ce disque se trouve typiquement sous votre profil Windows. Si votre disque système est lent, tout dans WSL2 hérite de cette lenteur — en particulier les couches de conteneurs, caches de paquets et artefacts de build.

Si vous voulez des performances WSL2, gardez les charges à fort churn dans le système de fichiers Linux (ext4 dans le VHDX) plutôt que de travailler depuis /mnt/c. L’interopérabilité du système de fichiers Windows est bonne, mais elle n’est pas « native Linux » bonne.

Docker Desktop et Kubernetes sur WSL2 : qui commande vraiment ?

Quand Docker intervient, beaucoup d’équipes perdent la trace de l’endroit où se situe le contrôle des ressources. Ils règlent les limites Docker, puis se demandent pourquoi vmmem continue de croître. Ou ils règlent WSL2 et se demandent pourquoi Kubernetes plante.

Comprendre la hiérarchie

• La limite VM WSL2 plafonne l’ensemble du Linux VM. Docker à l’intérieur est en aval de ce plafond.
• Les réglages de ressources Docker (si vous utilisez l’UI Docker Desktop) peuvent ou non s’appliquer comme vous le pensez selon le backend et la version. Quand le backend est WSL2, les limites WSL2 sont le plafond dur.
• Kubernetes ajoute du churn d’arrière-plan. Même des clusters « inactifs » font tourner des composants de control plane, des controllers et des watchers. C’est des réveils CPU réguliers et une empreinte mémoire.

Mon conseil opérationnel : décidez si votre portable est autorisé à héberger un cluster local et appliquez cette décision avec des limites. Si vous l’autorisez, budgétez-le. Ne le laissez pas être un passager accidentel.

Tâches pratiques : commandes, sorties et décisions

Voici les vérifications pratiques que j’utilise réellement. Chaque tâche inclut une commande, une sortie représentative et ce que vous en déduisez. Exécutez les commandes côté Windows dans PowerShell ; exécutez les commandes côté Linux dans WSL.

Tâche 1 : Confirmer la version WSL et ce qui tourne

cr0x@server:~$ wsl.exe --list --verbose
  NAME            STATE           VERSION
* Ubuntu-22.04    Running         2
  Debian          Stopped         2

Sens : Ubuntu tourne sur WSL2. Debian est arrêtée. Si vous pensiez que « rien ne tourne », vous aviez tort.

Décision : Si vmmem est élevé, concentrez-vous sur la/les distribution(s) en cours. Arrêtez ce que vous n’avez pas besoin.

Tâche 2 : Réinitialisation complète de WSL pour récupérer la mémoire hôte

cr0x@server:~$ wsl.exe --shutdown

Sens : Toutes les distributions WSL et la VM WSL2 sont terminées. La mémoire devrait chuter peu après.

Décision : Utilisez ceci quand Windows est sous pression maintenant. Ne l’utilisez pas comme rituel quotidien pour éviter de définir des limites.

Tâche 3 : Voir l’empreinte mémoire WSL côté hôte (rapide et sale)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process vmmem | Select-Object Name,Id,@{n='WS(MB)';e={[math]::Round($_.WorkingSet64/1MB,0)}},CPU"
Name  Id   WS(MB) CPU
vmmem 9480 10324  812.55

Sens : La VM tient environ 10 Go de working set. Le temps CPU indique qu’elle a été active.

Décision : Si Windows swappe et que c’est grand, appliquez un plafond mémoire et/ou arrêtez WSL.

Tâche 4 : Vérifier la mémoire à l’intérieur de WSL (séparer le cache de la pression)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.6Gi       2.1Gi       1.2Gi       128Mi       4.3Gi       5.1Gi
Swap:          4.0Gi       0.0Gi       4.0Gi

Sens : La plupart de la mémoire est en buff/cache, mais available est sain. Ce n’est pas une urgence à l’intérieur de Linux.

Décision : Si Windows va bien, ignorez. Si Windows ne va pas bien, les plafonds/la récupération comptent plus que de chasser le « used ».

Tâche 5 : Identifier les plus gros consommateurs mémoire (RSS réel, pas les impressions)

cr0x@server:~$ ps aux --sort=-rss | head -n 8
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1321  3.2  6.1 912648 475832 ?       Ssl  09:12   2:44 dockerd
cr0x      4882  1.1  4.8 2879300 376544 ?      Sl   10:01   0:51 node
cr0x      5021 18.9  4.2 1845500 332100 ?      Rl   10:05   1:32 rustc
postgres  2110  0.7  2.0  891200 158300 ?      Ssl  09:20   0:33 postgres
root       823  0.2  1.1  368012  88224 ?      Ss   09:10   0:08 containerd

Sens : Il s’agit de vraie mémoire de processus (RSS). Ici, Docker et les builds sont des consommateurs majeurs.

Décision : Si vous atteignez des plafonds, réduisez le parallélisme, arrêtez des services, ou déplacez les charges lourdes hors du portable.

Tâche 6 : Vérifier si vous swappez à l’intérieur de WSL

cr0x@server:~$ swapon --show
NAME      TYPE SIZE USED PRIO
/swapfile file   4G  512M   -2

Sens : Le swap est utilisé. Pas automatiquement mauvais, mais étiquette d’alerte performance.

Décision : Si la performance interactive est mauvaise, traitez l’usage du swap comme un déclencheur pour réduire la charge ou augmenter le plafond mémoire.

Tâche 7 : Trouver l’I/O wait (le disque est-il le vrai goulot ?)

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 524288 842000  68000 3380000  20   45  1200   800  560  940 18  7 62 13  0
 1  1 524288 812000  68000 3310000  10   25  2400  1900  620 1020 12  6 58 24  0
 0  1 524288 798000  68000 3290000   0   12  3100  2200  640 1090 10  5 52 33  0

Sens : wa (I/O wait) augmente. Swap in/out se produit. Vous payez maintenant des intérêts sur la dette mémoire.

Décision : Réduisez d’abord la pression mémoire. Si ça persiste, envisagez un emplacement de stockage plus rapide, moins de swap, ou moins de jobs concurrents.

Tâche 8 : Vérifier la contention CPU et la charge à l’intérieur de WSL

cr0x@server:~$ uptime
 10:14:22 up  1:08,  0 users,  load average: 9.12, 7.44, 5.81

Sens : La charge moyenne est élevée par rapport aux CPU alloués. Si vous avez plafonné à 4 CPU et que la charge est à 9, vous avez une file d’attente.

Décision : Soit augmentez processors, soit réduisez le parallélisme (make -j, outils de build, réplicas de conteneurs).

Tâche 9 : Confirmer combien de CPUs WSL voit

cr0x@server:~$ nproc
4

Sens : Votre VM WSL2 voit 4 CPUs. Cela correspond à un plafond processors=4.

Décision : Si les builds sont très lents mais que Windows est inactif, augmentez le plafond CPU. Si Windows souffre, gardez-le plafonné.

Tâche 10 : Localiser les véritables coupables d’usage disque dans WSL

cr0x@server:~$ sudo du -xh /var/lib | sort -h | tail -n 8
1.1G	/var/lib/apt
2.4G	/var/lib/snapd
6.2G	/var/lib/docker
6.2G	/var/lib/docker/overlay2
7.9G	/var/lib

Sens : Le stockage Docker domine. Cela corrèle aussi avec la pression mémoire (page cache, churn de métadonnées).

Décision : Prunez images/volumes, déplacez les builds, ou acceptez que l’accumulation locale de conteneurs ait un coût.

Tâche 11 : Voir les limites mémoire actuelles appliquées depuis Windows (sanity check)

cr0x@server:~$ cat /proc/meminfo | head -n 5
MemTotal:        7961888 kB
MemFree:         1214320 kB
MemAvailable:    5389120 kB
Buffers:           68040 kB
Cached:          3129480 kB

Sens : MemTotal est d’environ 7.6–7.9 Go, ce qui implique que votre plafond mémoire WSL2 est en place.

Décision : Si vous attendiez 16 Go et obtenez 8 Go, votre plafond est trop bas pour cette charge (ou c’est le bon plafond et la charge doit changer).

Tâche 12 : Vérifier les services systemd qui mangent des ressources en silence

cr0x@server:~$ systemctl --no-pager --type=service --state=running | head -n 12
  UNIT                         LOAD   ACTIVE SUB     DESCRIPTION
  cron.service                  loaded active running Regular background program processing daemon
  dbus.service                  loaded active running D-Bus System Message Bus
  docker.service                loaded active running Docker Application Container Engine
  rsyslog.service               loaded active running System Logging Service
  ssh.service                   loaded active running OpenBSD Secure Shell server
  systemd-journald.service      loaded active running Journal Service

Sens : Docker et SSH tournent, plus des services de base. C’est une empreinte d’arrière-plan réelle.

Décision : Arrêtez ce dont vous n’avez pas besoin. Si vous n’utilisez Docker qu’occasionnellement, ne le laissez pas idler indéfiniment.

Tâche 13 : Arrêter un service lourd et confirmer le delta

cr0x@server:~$ sudo systemctl stop docker
cr0x@server:~$ ps aux --sort=-rss | head -n 5
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
cr0x      4882  0.8  4.6 2879300 362112 ?      Sl   10:01   0:54 node
postgres  2110  0.7  2.0  891200 158100 ?      Ssl  09:20   0:33 postgres
root       823  0.1  0.9  342200  72140 ?      Ss   09:10   0:08 containerd

Sens : Les processus liés à Docker ont diminué. La mémoire devrait réduire avec le temps ; les réveils CPU diminueront immédiatement.

Décision : Si cela améliore sensiblement la réactivité de Windows, vous avez trouvé un contributeur majeur. Définissez une politique : ne laissez pas Docker tourner 24/7 si ce n’est pas voulu.

Tâche 14 : Confirmer que Windows voit les limites après redémarrage

cr0x@server:~$ wsl.exe --shutdown
cr0x@server:~$ wsl.exe -d Ubuntu-22.04 -- cat /proc/meminfo | head -n 1
MemTotal:        7961888 kB

Sens : La VM a redémarré et est toujours plafonnée à ~8 Go.

Décision : Si rien n’a changé, vous avez édité le mauvais fichier, utilisé une syntaxe invalide, ou oublié de redémarrer la VM.

Trois micro-histoires du monde corporate (parce que la production a toujours un avis)

Micro-histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe a déployé WSL2 comme environnement de développement par défaut. C’était une décision raisonnable : outils cohérents, moins de « marche sur ma machine », et onboarding plus simple. Ils ont dit à tout le monde « C’est léger ». Cette phrase a fait des dégâts.

En une semaine, les plaintes sur les portables ont afflué : VPN qui tombe, Teams qui se fige en pleine réunion, toute l’UI Windows saccadée. Le support a d’abord pointé la protection endpoint. Les développeurs ont blâmé les mises à jour Windows. La réalité était plus simple : les gens faisaient tourner des stacks conteneurs toute la journée, et la VM WSL2 s’est joyeusement étendue pour remplir la mémoire. L’hôte a commencé à paginer, et tout ce qui dépendait d’une latence prévisible a commencé à vaciller.

L’erreur n’était pas « WSL2 est mauvais ». C’était « WSL2 est petit par défaut ». Dans un monde VM, « par défaut » signifie souvent « sans plafond ». Ils ont résolu le problème en publiant un baseline .wslconfig standard (plafonds mémoire et CPU), plus une règle interne : si vous avez besoin de plus, vous en faites la demande et la justifiez.

La surprise : les temps de build ont à peine changé. La stabilité interactive s’est améliorée immédiatement. C’est ce qui arrive quand on arrête de se battre pour les 2 Go de RAM restants comme s’ils étaient un minéral rare.

Micro-histoire 2 : L’optimisation qui a mal tourné

Une autre organisation avait une croisade performance bien intentionnée : « Rendre les builds plus rapides en donnant plus de cœurs à WSL2. » Ils ont poussé une config qui mettait processors égal au nombre total de cœurs de la machine. Les compilations ont filé. Tout le monde publiait des captures d’écran. La dynamique était lancée.

Puis le retour de bâton : les développeurs utilisent aussi des IDE Windows, des navigateurs et des agents de sécurité. Donner tous les CPU à WSL2 n’a pas « volé » les cœurs définitivement, mais cela a créé une contention persistante. Les builds parallèles, les health checks de conteneurs et l’indexation en arrière-plan dans WSL2 produisaient des threads constamment runnable. Windows restait « réactif » dans le sens trivial (la souris bougeait) mais le travail sensible à la latence se dégradait : appels vidéo, partage d’écran, même la frappe avait du lag sous charge.

Ils ont essayé un second « fix » : baisser la mémoire WSL2 tout en gardant le CPU illimité. Cela a transformé le système en usine à swap. Les builds sont devenus plus lents qu’avant. Pire, ils sont devenus imprévisibles — rapides un jour, épouvantables un autre, selon ce qui tournait.

La vraie solution était ennuyeuse : plafonner le CPU à une fraction sensée, plafonner la mémoire pour protéger l’hôte, et régler le parallélisme de build par projet. Le débit de pointe a légèrement baissé. L’expérience médiane des développeurs s’est beaucoup améliorée. En entreprise, la médiane est ce que vous livrez.

Micro-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme maintenait un « profil de poste de travail dev connu bon ». Ce n’était pas glamour. C’était un petit ensemble de defaults : un fichier .wslconfig, une configuration Docker standard, et une checklist pour les gros repos. Les gens râlaient sur le contrôle centralisé, comme toujours, jusqu’à ce que quelque chose casse.

Puis une grosse mise à jour de dépendances est arrivée. Les builds ont grossi en usage mémoire, les images de conteneurs ont pris de l’ampleur, et les clusters de test locaux sont devenus plus lourds. L’organisation sans standards a commencé à lutter : « Pourquoi les machines de tout le monde fondent ? » L’organisation avec le profil a vu quelques ralentissements, certes, mais pas d’instabilité en masse.

Parce que leur profil incluait une pratique simple : avant de lancer de gros builds ou du travail cluster, les développeurs faisaient un contrôle rapide (mémoire disponible, usage swap, services en cours). Et après, ils arrêtaient WSL s’ils avaient fini. Ce n’était pas une automatisation fancy ; c’était de l’hygiène opérationnelle.

Quand la montée de dépendances a augmenté les besoins mémoire, l’équipe plateforme a ajusté les limites de base prudemment et a communiqué les compromis. Personne n’a adoré, mais personne n’a perdu une journée à cause d’un lag mystérieux. L’ennui a encore sauvé la mise. C’est en gros le SRE en une phrase.

Erreurs courantes : symptôme → cause racine → correction

1) Symptôme : Windows est lent, le Gestionnaire affiche vmmem utilisant « trop » de RAM

Cause racine : La VM WSL2 a gonflé à cause du page cache ou de la mémoire de la charge, et l’hôte est maintenant sous pression mémoire.

Correction : Définissez memory= dans .wslconfig, puis wsl.exe --shutdown. Si vous avez besoin de récupérer la mémoire immédiatement, arrêtez d’abord, puis ajustez.

2) Symptôme : WSL2 est lent même si vous « lui avez donné des limites »

Cause racine : Les limites sont trop strictes et Linux swappe ou récupère constamment le cache.

Correction : Vérifiez swapon --show et vmstat. Augmentez memory ou réduisez le parallélisme de la charge. Ne sous-alimentez pas l’invité en espérant la vitesse.

3) Symptôme : CPU saturé, l’UI Windows stutter pendant les builds

Cause racine : WSL2 a trop de vCPUs ou les outils de build oversubscribent les threads.

Correction : Mettez processors= à une valeur sensée. Réglez aussi la concurrence des builds (par exemple, baissez -j ou le nombre de workers des outils).

4) Symptôme : vmmem reste gros après avoir arrêté des processus Linux

Cause racine : Le page cache reste alloué ; la récupération côté hôte n’est pas immédiate.

Correction : Acceptez-le si l’hôte a de la marge. Si non, utilisez wsl.exe --shutdown et implémentez des plafonds pour qu’il ne dépasse pas le budget.

5) Symptôme : Disque occupé, ventilateurs qui tournent, tout se bloque périodiquement

Cause racine : Swap et activité lourde du système de fichiers (souvent les overlays Docker) provoquant des pics d’I/O wait.

Correction : Réduisez la pression mémoire, nettoyez le stockage Docker, évitez les builds lourds sur /mnt/c, et gardez le swap modéré. Si vous avez besoin de beaucoup de mémoire, augmentez la RAM plutôt que de « tuner » à outrance.

6) Symptôme : Le réseau semble lent ; on blâme le CPU ou la mémoire

Cause racine : Souvent une mauvaise configuration DNS, une interaction VPN, ou des problèmes de localhost forwarding — masqués en « lenteur système ».

Correction : Vérifiez réellement si WSL est CPU/mémoire lié avant de tuner. Gardez localhostForwarding=true sauf raison particulière.

7) Symptôme : Après avoir édité .wslconfig, rien ne change

Cause racine : Le fichier est au mauvais endroit, la syntaxe est invalide, ou WSL n’a pas été redémarré.

Correction : Assurez-vous qu’il est dans le chemin du profil utilisateur Windows, validez les clés, puis wsl.exe --shutdown et relancez la distribution. Confirmez avec /proc/meminfo et nproc.

Listes de contrôle / plan pas à pas

Plan A : Empêcher WSL2 de manger votre RAM (sans casser votre flux)

1. Mesurez d’abord. Vérifiez le working set de vmmem et la pression mémoire Windows.
2. Inventoriez ce qui tourne. wsl.exe --list --verbose, puis à l’intérieur de WSL vérifiez les processus en tête.
3. Décidez votre budget. Choisissez plafonds mémoire et CPU selon la RAM/les cœurs de l’hôte et ce qui doit rester réactif sur Windows.
4. Appliquez .wslconfig. Définissez memory, processors et swap intentionnellement.
5. Redémarrez WSL. wsl.exe --shutdown et relancez votre distribution.
6. Validez les limites. Utilisez /proc/meminfo et nproc.
7. Surveillez le swap. Si le swap grossit pendant le travail normal, les limites sont trop basses ou la charge est trop lourde.
8. Corrigez la charge. Arrêtez les services d’arrière-plan inutiles, nettoyez le stockage de conteneurs, réduisez le parallélisme des builds.

Plan B : Votre portable est déjà en feu (mode triage)

1. Relief immédiat : wsl.exe --shutdown.
2. Confirmez que Windows se remet : la mémoire baisse, le disque arrête de thrash, l’UI redevient réactive.
3. Appliquez des plafonds avant de relancer des charges lourdes : créez ou ajustez .wslconfig.
4. Redémarrez seulement ce dont vous avez besoin : lancez une seule distribution ; évitez d’auto-démarrer Docker/Kubernetes tant que vous n’êtes pas stable.
5. Rejouez le plan de diagnostic rapide : vérifiez si le prochain goulot est CPU, mémoire ou disque.

Plan C : Rendre cela durable pour les équipes

1. Standardisez une baseline. Publiez un .wslconfig recommandé pour les paliers de portables (16 Go, 32 Go).
2. Définissez des chemins d’escalade. Si quelqu’un a besoin de 20 Go dans WSL2, c’est une demande matérielle ou une stratégie de build à distance, pas un tweak local secret.
3. Enseignez « le cache n’est pas mal ». Apprenez aux gens à lire la mémoire available, l’usage du swap et l’I/O wait.
4. Construisez avec des budgets. Le CI devrait représenter la réalité ; ne laissez pas les environnements locaux s’étendre en mini-datacenters sans garde-fous.

FAQ

1) Pourquoi WSL2 utilise-t-il tant de RAM même quand je « ne fais rien » ?

Parce que Linux cache agressivement et WSL2 est une VM. « Rien » inclut souvent des daemons Docker, des watchers, des language servers et des données de cache de système de fichiers. Vérifiez free -h et regardez available vs buff/cache.

2) Est-il sûr de plafonner la mémoire WSL2 ?

Oui. C’est souvent la bonne action. Le risque est de la régler trop bas et forcer le swap ou des OOM kills dans Linux. Plafonnez assez haut pour votre charge réelle, pas votre charge optimiste.

3) Pourquoi fermer mes apps Linux ne réduit-il pas immédiatement vmmem dans le Gestionnaire ?

Parce que la VM peut encore garder de la mémoire pour le cache et l’hôte ne la récupère pas instantanément. Si Windows a besoin de cette mémoire maintenant, arrêtez WSL. Si Windows va bien, ne paniquez pas pour un chiffre.

4) wsl.exe --shutdown supprime-t-il quelque chose ?

Non. Cela termine les instances WSL. Vos fichiers et l’état de la distribution persistent sur le disque. Vous perdrez les sessions en mémoire et tout état volatile, comme après un reboot.

5) Dois-je régler le swap à 0 ?

Parfois. Si vous préférez échouer rapidement (OOM) plutôt que d’avoir un thrash lent, désactiver le swap peut être défendable. Pour la plupart des développeurs, un swap modéré est une sécurité. Si vous le désactivez, préparez-vous à des kills de processus abrupts sous pression.

6) Quelle valeur processors est sensée ?

La moitié de vos cœurs est un bon défaut. Si vous avez 8 cœurs, donnez 4 à WSL2. Si vous avez 16, donnez 6–8. Si vous faites des compilations parallèles lourdes et que Windows est par ailleurs inactif, augmentez. Si vous tenez à la réactivité UI, plafonnez.

7) Travailler dans /mnt/c est-il plus lent que dans le système de fichiers Linux ?

Typiquement oui — surtout pour les workloads avec beaucoup de petites opérations fichier (node_modules, dossiers target Rust, couches de conteneurs). Gardez les arbres de build lourds dans le système de fichiers de la distribution pour la performance et moins de cas limites bizarres.

8) J’utilise Docker Desktop avec WSL2. Dois-je tuner Docker ou WSL ?

Commencez par WSL2 car c’est le plafond dur pour la VM. Ensuite, ajustez les charges Docker (prune des images, ajuster les réplicas compose, définir des limites mémoire de conteneurs) pour rester sous ce plafond.

9) Puis-je définir des limites différentes par distribution ?

.wslconfig est global pour le comportement VM WSL2. Si vous avez besoin d’isolation par distro, vous entrez dans le territoire « utiliser des VMs séparées ou d’autres outils », pas seulement les réglages WSL2.

10) Comment savoir si mon problème est mémoire ou disque ?

Cherchez l’activité swap et l’I/O wait. Dans WSL, swapon --show vous dit si le swap est utilisé ; vmstat montre wa et les swaps in/out. Si wa est élevé et que le swap est actif, le disque est devenu le goulot.

Prochaines étapes qui tiennent dans le temps

Si WSL2 vous mange la RAM, ne le traitez pas comme un bug Windows effrayant. Traitez-le comme ce qu’il est : une VM exécutant un vrai OS avec un vrai comportement de cache. Ensuite faites ce que font les adultes dans les systèmes de production : fixez des budgets, mesurez et répondez à la pression tôt.

1. Choisissez un budget aujourd’hui : réglez memory et processors dans .wslconfig et redémarrez WSL.
2. Validez avec des preuves : confirmez que /proc/meminfo et nproc correspondent à votre intention.
3. Surveillez le swap et l’I/O wait : si vous les voyez pendant le travail normal, augmentez le plafond ou réduisez la charge.
4. N’arrondissez pas les services lourds : Docker/Kubernetes doivent être un choix délibéré, pas un style de vie en arrière-plan.
5. Utilisez shutdown comme outil, pas béquille : c’est un bon levier d’urgence, mais les limites sont la solution long terme.

Une fois cela fait, WSL2 redevient ce qu’il doit être : un environnement Linux solide sur Windows. Pas un colocataire non invité avec des opinions bien arrêtées sur votre budget mémoire.