Mémoire élevée de VmmemWSL : identifier la charge avant de récupérer la RAM

VmmemWSL dans le Gestionnaire des tâches représente les ressources utilisées par l'environnement de machine virtuelle WSL. Sa mémoire peut inclure des charges Linux actives et du cache. Si Docker, un serveur de modèles IA ou des outils de développement y fonctionnent, fermer un éditeur Windows n'arrête pas nécessairement ce travail.

Déterminez d'abord si la mémoire appartient à une tâche en cours ou reste en cache après la fin de la tâche. Supprimer un disque virtuel WSL n'est pas une solution au problème de mémoire et peut détruire l'environnement Linux et ses données.

Identifier le travail à l'intérieur de WSL

Depuis PowerShell, inspectez l'environnement installé :

wsl --version
wsl --list --verbose
wsl --list --running

Dans la distribution Linux concernée, utilisez ces vues en lecture seule :

free -h
ps -eo pid,comm,rss --sort=-rss

Les relevés Linux n'ont pas exactement la même portée que le total de la machine virtuelle dans le Gestionnaire des tâches. Utilisez-les pour localiser les processus et distinguer la mémoire disponible du cache de fichiers, sans forcer chaque chiffre à correspondre. Pour le travail géré par Docker, inspectez les conteneurs en cours d'exécution dans Docker Desktop et arrêtez la tâche visée par son contrôle habituel.

Un serveur IA peut garder un modèle chargé après avoir répondu. Arrêtez cette charge délibérément si elle n'est plus nécessaire. Ne tuez pas un processus arbitraire simplement parce que son nom ne vous est pas familier.

Lire un échantillon de mémoire Linux sans qualifier chaque cache de fuite

Dans la sortie free -h, faites attention à available ainsi qu'à used et buff/cache. Linux utilise la mémoire autrement inactive pour les données de fichiers, et une partie de cette mémoire peut être récupérée lorsque les applications en ont besoin. Une valeur free faible ne suffit donc pas à établir que Linux est à court de mémoire.

La liste des processus indique le RSS en KiB, tandis que free -h utilise des unités lisibles par l'humain. Les pages partagées et la surcharge de la VM font aussi que la somme des lignes de processus n'égale pas nécessairement le chiffre VmmemWSL du Gestionnaire des tâches. Utilisez les lignes les plus importantes pour identifier le propriétaire, puis inspectez la charge de travail nommée, plutôt que de forcer les totaux à correspondre.

Si Docker est impliqué, ces commandes en lecture seule identifient les conteneurs en cours d'exécution et prélèvent un échantillon de ressources, conformément à la référence Docker stats :

docker ps
docker stats --no-stream

Exécutez-les dans l'environnement connecté au backend Docker étudié. Un contexte Docker différent peut décrire une machine distante, vérifiez donc la cible avant d'agir. Le chiffre de mémoire affiché pour un conteneur et le total de la VM WSL entière ont des portées différentes.

Comparez trois états : avant le démarrage de la tâche d'IA, pendant son exécution et après que l'application a normalement déchargé son modèle ou arrêté la tâche. Si le processus volumineux reste actif, la récupération du cache ne remplace pas la décision de savoir si ce processus doit continuer à s'exécuter. Si le processus diminue mais que le cache demeure, le comportement de récupération devient une question plus pertinente.

Vérifier le réglage de récupération actuel

La référence de configuration WSL de Microsoft place les paramètres globaux de WSL 2 dans %USERPROFILE%\.wslconfig. Ce fichier est différent de /etc/wsl.conf à l'intérieur d'une distribution.

La référence actuelle liste autoMemoryReclaim sous [experimental], avec dropCache comme valeur par défaut et gradual comme autre mode pris en charge. Les anciens conseils invitant à activer une valeur par défaut universellement désactivée peuvent donc être obsolètes. Vérifiez la version de WSL installée et votre configuration existante avant d'ajouter quoi que ce soit.

Si vous souhaitez délibérément une récupération progressive du cache sur une version prenant en charge ce réglage, fusionnez cette entrée dans le fichier existant :

[experimental]
autoMemoryReclaim=gradual

N'écrasez pas de réglages sans rapport et ne créez pas de sections en double. Cela modifie la façon dont la mémoire mise en cache est récupérée ; cela ne réduit pas les besoins en mémoire d'un modèle ou d'une base de données actifs. Comparez la même charge de travail avant de décider de conserver la modification.

Modifier la configuration existante et garder un moyen de revenir en arrière

Ouvrez %USERPROFILE% dans l'Explorateur de fichiers et activez l'affichage des extensions de noms de fichiers avant de créer ou de modifier .wslconfig. Un fichier accidentellement enregistré sous .wslconfig.txt n'est pas la configuration voulue. Copiez d'abord une configuration existante vers une sauvegarde et conservez les sections sans rapport avec la mémoire.

Sous une section [experimental] existante, ne modifiez que l'entrée de récupération testée. Un nouveau fichier n'est nécessaire que si aucune configuration n'existe et qu'un changement de réglage intentionnel se justifie. N'ajoutez pas à la fois des lignes dropCache et gradual et ne dupliquez pas la section après avoir copié des exemples provenant d'articles différents.

La valeur par défaut documentée par Microsoft récupère déjà le cache. La remplacer par gradual est une expérience de politique, pas une amélioration qui économise toujours plus de mémoire. Elle peut laisser le cache résident plus longtemps qu'une récupération immédiate. Si aucun problème n'est démontré avec le comportement actuel, laissez la valeur par défaut en place et étudiez plutôt la charge de travail active.

Après avoir appliqué un changement au moyen d'un redémarrage sûr de WSL, répétez la même tâche et observez la réactivité de Windows, la mémoire disponible sous Linux et si la tâche s'achève. Si le changement n'est pas utile, restaurez l'entrée précédente depuis la sauvegarde, puis appliquez cette restauration avec les mêmes précautions d'enregistrement et de redémarrage. N'effacez pas toute la configuration pour supprimer une seule ligne expérimentale.

Redémarrer WSL uniquement après avoir sauvegardé son travail

Les modifications de configuration s'appliquent au redémarrage de l'environnement WSL. Les commandes de base de Microsoft documentent la commande d'arrêt global :

wsl --shutdown

Avant de l'utiliser, sauvegardez les fichiers, arrêtez les tâches d'entraînement ou d'inférence et arrêtez normalement les conteneurs ou bases de données concernés. La commande arrête toutes les distributions en cours d'exécution et la machine virtuelle WSL 2, y compris le travail derrière Docker Desktop. Ce n'est pas un bouton de réduction sélective de la mémoire.

Si la mémoire de VmmemWSL disparaît après l'arrêt, cela confirme que l'environnement arrêté en était propriétaire. Cela ne permet pas de distinguer une fuite d'une tâche active ou d'un cache utile. Redémarrez les services nécessaires et comparez une fois le même travail terminé.

Utiliser un plafond de mémoire comme budget, pas comme réparation

Le réglage .wslconfig memory limite la mémoire disponible de WSL 2. Un plafond trop bas peut faire échouer les applications Linux ou provoquer un recours intensif au swap. Il ne supprime pas le besoin d'un programme. Ne le choisissez qu'après avoir mesuré la charge de travail et la RAM dont Windows a aussi besoin, puis vérifiez que l'application se termine correctement.

Les conseils WSL de Docker Desktop abordent la récupération de mémoire pour son backend WSL. Conservez la configuration à ce niveau de backend plutôt que d'appliquer des instructions Hyper-V sans rapport.

Confirmer qu'un plafond de mémoire a réellement pris effet

Si un plafond est nécessaire, placez memory sous [wsl2] dans la configuration existante. Par exemple, memory=8GB signifie une limite de 8 Go, et non 8 Go réservés à chaque distribution. C'est un exemple de syntaxe, pas un budget recommandé pour tous les PC. Plusieurs distributions WSL 2 partagent le budget global de la VM, tenez donc compte de leur travail simultané au moment de le choisir.

Après avoir enregistré votre travail et redémarré WSL, inspectez le total rapporté par free -h dans une distribution et comparez-le à la limite prévue, en tenant compte de la surcharge système. Exécutez ensuite le modèle ou la compilation réelle. Un chiffre plus faible dans le Gestionnaire des tâches n'est pas une réussite si la tâche Linux est désormais tuée ou passe son temps à échanger.

Si la limite semble ignorée, vérifiez le compte Windows propriétaire du fichier, son extension, si la distribution cible est bien WSL 2 et si l'ancienne VM s'est complètement arrêtée. Ces vérifications sont plus instructives que d'abaisser répétitivement la valeur. Ne désactivez pas l'échange comme seconde expérience simultanée, car cela change le comportement de la charge de travail lorsqu'elle atteint son budget.

Pour les charges de travail Docker, préservez le comportement normal d'arrêt et de persistance des données de Docker. Fermer un terminal n'arrête pas nécessairement son conteneur, tandis qu'un arrêt global de WSL peut interrompre plusieurs services sans rapport. Enregistrez le travail de base de données et d'entraînement via leurs propres contrôles d'application avant d'appliquer un changement à l'échelle de la VM.

Garder la RAM et l'espace du disque virtuel séparés

Le guide de la mémoire Windows couvre les relevés côté hôte. Pour la capacité de disque, utilisez le guide de stockage Docker et WSL séparé. N'utilisez jamais wsl --unregister comme raccourci de nettoyage : cela supprime une distribution et ses données au lieu de résoudre un relevé de mémoire élevée.