Wir müssen reden. WSL 2 ist extrem schnell – bis sie es plötzlich nicht mehr ist.
Wenn du Teil 7 umgesetzt hast und aktiv mit Docker arbeitest, hast du ihn vermutlich schon gesehen: den Prozess vmmem im Windows-Task-Manager. Erst 2 GB, dann 4 GB, irgendwann 8 GB RAM – und Windows fängt an zu schwimmen.
Ich habe das selbst erlebt, als ein eigentlich harmloser Next.js-Build meinen Laptop plötzlich so ausgebremst hat, als hätte ich wieder eine rotierende HDD verbaut. In diesem Teil zeige ich dir, wie du WSL 2 kontrollierst, statt dich von ihr kontrollieren zu lassen.
Dieser Artikel basiert auf jahrelanger praktischer Arbeit mit WSL 2, Docker und großen Webprojekten unter Windows und dokumentiert reale Performance-Probleme samt erprobter Lösungen aus dem Entwickleralltag.
Den RAM-Hunger bändigen: die .wslconfig
WSL 2 ist technisch gesehen eine virtuelle Maschine. Der große Vorteil: Sie nimmt sich dynamisch Ressourcen von Windows. Der große Nachteil: Sie gibt sie nicht zuverlässig zurück.
Besonders speicherhungrig sind in der Praxis:
Docker-Builds
große TypeScript-Projekte
ESLint & Language Server in Monorepos
Die Lösung ist keine Optimierung innerhalb von Linux, sondern eine klare Grenze von Windows-Seite.
Die .wslconfig anlegen
Pfad (Windows):
C:\Users\<DeinName>\.wslconfig
Bewährtes Setup aus der Praxis:
[wsl2]
# Maximaler RAM für WSL (z. B. 8 GB bei 16 GB Gesamt-RAM)memory=8GB# Begrenze CPU-Kerneprocessors=4# Gibt ungenutzten Speicher schrittweise zurückautoMemoryReclaim=gradual# Stabilere Netzwerk-Integration (wichtig bei VPNs)networkingMode=mirrored
dnsTunneling=true
Warum das wichtig ist: Ohne diese Datei verhält sich WSL 2 wie ein Mitbewohner ohne Mietvertrag. Mit ihr wird sie berechenbar – und genau das brauchst du im Alltag.
Nach Änderungen immer:
wsl --shutdown
Das Dateisystem-Problem (der häufigste Performance-Killer)
Ich sage es bewusst deutlich, weil es immer noch falsch gemacht wird:
Code gehört nicht nach /mnt/c
Der Zugriff auf Windows-Dateien erfolgt über das 9p-Protokoll. Das ist funktional – aber langsam. Sehr langsam.
Besonders betroffen:
node_modules
vendor
Git-Operationen
Build-Tools
Realistische Performance-Unterschiede
Aufgabe
Windows (/mnt/c)
WSL 2 (ext4)
Dateisuche (fd)
~50 ms
~8 ms
npm install
spürbar zäh
sehr schnell
Build-Prozesse
inkonsistent
stabil
Die exakten Zahlen variieren je nach Hardware – der Unterschied in der Größenordnung bleibt.
Auch Windows 11 Dev Drive (ReFS) ändert daran nichts: WSL 2 arbeitet immer innerhalb ihrer eigenen virtuellen Festplatte.
Fazit: Projekte nach ~/projects verschieben. Diskussion beendet.
Troubleshooting: Die echten 90-%-Fixes
WSL oder VS Code fühlt sich „kaputt“ an
Fehlerbilder:
VS Code verliert die Verbindung
WebSocket-Fehler (1006)
Terminal reagiert träge
Der wichtigste Befehl überhaupt:
wsl --shutdown
Nicht Terminal schließen. Nicht neu starten. WSL hart beenden.
Das löst erfahrungsgemäß den Großteil aller Probleme.
Das ist nichts für jeden Tag – aber wichtig, wenn SSD-Platz knapp wird.
FAQ – Performance & Stabilität
Warum wird mein Laptop so heiß? Meist durch Datei-Watcher (ESLint, TSServer). Große Ordner in files.watcherExclude ausschließen.
Kann ich WSL auf eine andere Festplatte verschieben? Ja, über wsl --export und wsl --import. Ideal bei kleiner System-SSD.
Warum ist git status langsam? Fast immer liegt das Projekt auf /mnt/c. Verschieben nach ~/.
Einordnung aus der Praxis
WSL 2 ist kein Spielzeug. Sie ist auch kein klassischer Linux-Server.
Behandle sie wie einen lokalen Entwicklungs-Container, der bewusst gepflegt werden muss. Dann ist sie stabil, schnell – und langfristig angenehm.
Ausblick auf Teil 9
Im letzten Teil der Serie geht es um Git-Workflows unter WSL 2:
SSH-Keys sauber trennen
Windows- & Linux-Git vermeiden
Line Endings, Permissions, Repositories
typische Fehlerquellen im Team
Damit schließt sich der Kreis von Setup → Performance → produktivem Arbeiten.
Über den Autor
Webinteger arbeitet seit vielen Jahren produktiv mit Linux-basierten Entwicklungsumgebungen unter Windows. Der Fokus liegt auf performanten Setups mit WSL 2, Docker, PHP, Node.js und modernen Build-Tools in realen Projekten – nicht auf theoretischen Beispielkonfigurationen.
Die Artikel dieser Serie entstehen direkt aus dem täglichen Einsatz in Kunden- und Eigenprojekten und dokumentieren bewusst auch typische Fehler, Engpässe und bewährte Workarounds.
