Docker auf WSL 2 langsam? So optimieren Sie CPU und RAM für SonarQube-Scans

Wenn Sie Docker Desktop auf Windows nutzen und dabei Anwendungen wie SonarQube ausführen, die viel Rechenleistung und Arbeitsspeicher benötigen, kann es schnell frustrierend werden. Plötzlich laufen die Scans im Schneckentempo, während Ihr Host-System scheinbar noch Ressourcen frei hat. Der Grund dafür liegt oft in der Konfiguration der WSL 2-Virtualisierungsschicht, die Docker nutzt. Eine einfache Anpassung der .wslconfig-Datei kann hier Wunder wirken – und ist in wenigen Minuten erledigt.

Warum SonarQube-Scans unter Docker auf Windows stocken

Bei mir selbst trat das Problem auf, als ich einen SonarQube-Scan auf einem mittelgroßen Codebase innerhalb eines Docker-Containers durchführte. Die Analyse begann zwar, verlangsamte sich jedoch nach wenigen Minuten spürbar oder blieb sogar komplett stehen. Die Logs von SonarQube warnten nicht vor einem Speichermangel, und auch das Windows-System selbst schien genug Ressourcen zur Verfügung zu haben. Doch die tatsächlichen Limits lagen woanders: in der WSL 2-VM, die Docker Desktop für Windows nutzt.

Um das zu überprüfen, können Sie direkt in der WSL 2-Umgebung nachfragen, wie viele CPU-Kerne und wie viel Arbeitsspeicher tatsächlich verfügbar sind. Führen Sie dazu folgende Befehle in der PowerShell aus:

wsl -d docker-desktop -- nproc
wsl -d docker-desktop -- free -h

Die Ausgabe bei mir zeigte ein ernüchterndes Ergebnis:

• 1 CPU-Kern
• Weniger als 1 GB RAM

Das erklärt, warum selbst einfachere Analysen ins Stocken gerieten. SonarQube benötigt für den Java-Heap und die Analyseprozesse deutlich mehr Ressourcen. Sobald die Anwendung in eine speicherintensive Phase geriet, begann das System zu thrashen – der Arbeitsspeicher wurde auf die langsame Swap-Partition ausgelagert, was die Performance massiv beeinträchtigte.

Die Lösung: .wslconfig anpassen – so geht’s

Die Lösung liegt in einer einfachen, aber oft übersehenen Konfigurationsdatei: .wslconfig. Diese Datei wird von WSL 2 genutzt, um globale Einstellungen für die virtuelle Maschine vorzunehmen. Standardmäßig existiert sie nicht – Sie müssen sie selbst erstellen.

Speichern Sie die Datei unter folgendem Pfad ab:

C:\Benutzer\<IhrBenutzername>\.wslconfig

Der Inhalt der Datei sollte mindestens diese drei Zeilen enthalten:

[wsl2]
memory=8GB
processors=4
swap=8GB

Damit weisen Sie der WSL 2-VM 8 GB Arbeitsspeicher, vier CPU-Kerne und eine 8-GB-Swap-Partition zu. Das reicht für die meisten SonarQube-Analysen aus und verhindert, dass die Anwendung an Ressourcenmangel scheitert.

Bei der Einrichtung gab es jedoch einige Fallstricke, die mir fast zum Verhängnis wurden:

• Der Abschnittsname muss exakt `[wsl2]` lauten – in Kleinbuchstaben und ohne Leerzeichen.
• Größenangaben erfordern Einheiten wie GB oder MB. Ohne Einheit wird die Angabe in Bytes interpretiert. swap=4 bedeutet also nicht 4 GB, sondern 4 Byte – ein klassischer Fehler!
• Keine Leerzeichen um das Gleichheitszeichen verwenden.
• `processors` ist eine ganze Zahl ohne Nachkommastellen.

Änderungen übernehmen und überprüfen

Nach dem Speichern der .wslconfig-Datei müssen Sie die WSL 2-VM neu starten. Führen Sie dazu folgende Schritte in der PowerShell aus:

wsl --shutdown

Schließen Sie anschließend Docker Desktop über das Benachrichtigungsfeld und starten Sie es neu. Warten Sie etwa 8 Sekunden, bevor Sie Docker Desktop wieder öffnen – so lange dauert es laut Microsoft, bis die VM vollständig heruntergefahren ist. Überprüfen Sie den Status mit:

wsl --list --running

Falls keine Liste mit laufenden Instanzen erscheint, können Sie Docker Desktop gefahrlos neu starten. Nach dem Neustart sollten die Ressourcen nun deutlich höher ausfallen:

PS> wsl -d docker-desktop -- nproc
4
PS> wsl -d docker-desktop -- free -h
              total        used        free      shared  buff/cache   available
Mem:         7.8G        485.8M      6.6G        3.1M       697.7M      7.1G
Swap:        8.0G        0           8.0G

Jetzt stehen vier CPU-Kerne, etwa 7,8 GB RAM (die 8 GB abzüglich etwas Overhead) und eine vollständige 8-GB-Swap-Partition zur Verfügung – genau wie in der Konfiguration festgelegt. Der nächste SonarQube-Scan verlief deutlich schneller und beendete sich ohne Probleme.

Zusätzliche Optionen für die WSL 2-Konfiguration

Die .wslconfig bietet noch weitere Einstellungen, die für rechenintensive Workloads wie SonarQube nützlich sein können. Hier ein Beispiel mit einigen zusätzlichen Optionen:

[wsl2]
memory=8GB
processors=4
swap=8GB
vmIdleTimeout=60000
[experimental]
autoMemoryReclaim=gradual
sparseVhd=true

• `vmIdleTimeout=60000`: Die VM wird nach 60 Sekunden ohne Aktivität heruntergefahren, sodass sie nicht dauerhaft Ressourcen belegt.
• `autoMemoryReclaim=gradual`: Freigegebener Speicher wird langsam an das Host-System zurückgegeben, statt abrupt. Das ist besonders bei Anwendungen mit starken Speicherschwankungen vorteilhaft.
• `sparseVhd=true`: Neue WSL-VHD-Dateien werden als sparse-Dateien erstellt, sodass der tatsächliche Speicherplatzbedarf sinkt, wenn innerhalb der VM Speicher freigegeben wird.

Häufige Fehler und wie Sie sie vermeiden

Bei der Konfiguration der .wslconfig gibt es einige typische Fallstricke, die zu unnötigen Problemen führen können:

• Nicht alles einem einzigen Prozess zuweisen: Wenn Sie die gesamte RAM-Kapazität Ihres Systems oder alle CPU-Kerne an die WSL 2-VM zuweisen, leidet die Performance des Host-Systems. Microsoft empfiehlt, etwa 75 % des verfügbaren RAMs und zwei bis drei CPU-Kerne für die VM zu reservieren.

• Veraltete oder falsche Schlüssel ignorieren: Ein häufiger Fehler ist die Verwendung veralteter Optionen wie pageReporting, die in der aktuellen WSL 2-Spezifikation nicht mehr unterstützt werden. WSL 2 ignoriert unbekannte Schlüssel einfach, sodass die Konfiguration zwar syntaktisch korrekt erscheint, aber keine Wirkung entfaltet.

• Pfade richtig angeben: Wenn Sie Pfade wie swapFile oder kernel angeben, müssen Sie Backslashes doppelt schreiben, z. B. C:\Temp\swap.vhdx. Ein einzelner Backslash führt zu Fehlern.

• Die richtige VM adressieren: Wenn Sie die Ressourcen überprüfen, achten Sie darauf, den Befehl wsl -d docker-desktop -- free -h zu verwenden. Der Befehl wsl -- free -h prüft stattdessen die Standard-VM (z. B. Ubuntu), die für Docker irrelevant ist.

Fazit: Mehr Power für Docker auf Windows

Wenn Docker Desktop auf Windows langsamer läuft als erwartet, lohnt sich ein Blick auf die zugrundeliegende WSL 2-Konfiguration. Mit einer einfachen .wslconfig-Datei können Sie die Ressourcen der VM gezielt anpassen und so die Performance von rechenintensiven Anwendungen wie SonarQube deutlich verbessern. Der Aufwand ist minimal, die Wirkung jedoch enorm. Nach einem Neustart der VM und Docker Desktop sollten Ihre Scans wieder flüssig laufen – und Sie können sich auf die eigentlichen Aufgaben konzentrieren.

Testen Sie die Konfiguration und passen Sie die Werte je nach Bedarf an. Mit den richtigen Einstellungen wird Docker auf Windows zum leistungsstarken Werkzeug, das Ihre Entwicklungsarbeit spürbar beschleunigt.