Why Is SonarQube Running So Slowly on Windows? The Hidden Resource Limit in WSL 2
If your SonarQube scans (or any CPU- and memory-hungry container) are crawling on Docker Desktop for Windows, the culprit is often a nearly invisible resource cap inside the WSL 2 virtual machine. I recently discovered that my Docker-in-WSL 2 VM had just 1 CPU and 1 GB of RAM — no wonder my scan felt like molasses. The fix was a quick edit to a single configuration file. This guide walks you through the symptoms, diagnosis, fix, and verification steps, all in a Q&A format.
What are the telltale signs that SonarQube is starved for resources?
When SonarQube lacks sufficient CPU or memory, scans on a mid-sized codebase will chug along for a few minutes, then either crawl to a snail’s pace or stall completely. You might notice your PC's fans spinning up, but the scan never finishes. The SonarQube logs won't scream “out of memory” – they’ll just show the analyzer making painfully slow progress. The host system itself feels fine, so it's not a general Windows resource shortage. Instead, the bottleneck is inside the WSL 2 virtual machine that Docker Desktop uses to run containers. That VM has a hidden resource limit that defaults to a tiny slice of your hardware, which is catastrophic for Java-based tools like SonarQube that need a few gigabytes of heap and multiple CPU cores to work efficiently.
How do I check the actual CPU and RAM available to Docker containers under WSL 2?
Docker Desktop on Windows runs all containers inside a lightweight VM called docker-desktop, which is managed by WSL 2. To query its resources, open PowerShell (or Command Prompt) and run two commands: wsl -d docker-desktop -- nproc checks the number of logical CPUs, and wsl -d docker-desktop -- free -h shows memory and swap. On my machine, the output was stark: 1 for CPU and Mem: 907M total – less than 1 GB of RAM. The default allocation for WSL 2 VMs is shockingly low: often just 1 CPU core and 1 GB of RAM. That’s a fraction of what a typical Windows machine offers, and it explains why any memory-hungry container chokes. The diagnosis is straightforward – just ask the VM what it has.
What is the .wslconfig file and how do I edit it to fix the resource limits?
The .wslconfig file is WSL 2’s global configuration file, located at %UserProfile%\.wslconfig. You have to create it if it doesn’t exist. It’s a plain text file that sets memory, CPU, and swap limits for all WSL 2 VMs. The fix is just three lines:
[wsl2]
memory=8GB
processors=4
swap=8GBKey syntax gotchas: the section header must be [wsl2] (lowercase, exact), memory and swap require a unit (GB or MB) – omitting the unit means bytes, so swap=4 gives you 4 bytes, not 4 GB. No spaces around the equals sign. Processors is a plain integer; set it to the number of logical cores you want to give the VM.
How do I apply the .wslconfig changes and make Docker Desktop use the new limits?
After saving the .wslconfig file to C:\Users\<your-username>\.wslconfig, open PowerShell and run wsl --shutdown. This command stops all WSL 2 VMs, including the docker-desktop VM. But don’t restart Docker immediately – Microsoft recommends waiting about 8 seconds to let the VM fully terminate. You can verify with wsl --list --running – if no VMs are listed, it’s safe to proceed. Then quit Docker Desktop from the system tray icon and launch it again. Docker Desktop will automatically create a new WSL 2 VM that reads your updated config. The whole process takes less than a minute.
How can I verify that the new resource limits are actually in effect?
Once Docker Desktop is back up, run the same diagnostic commands as before: wsl -d docker-desktop -- nproc and wsl -d docker-desktop -- free -h. After my fix, the output showed 4 CPUs, Mem: 7.8G total (the 8 GB cap minus overhead), and Swap: 8.0G. The scan that had been crawling finished in just a few minutes. If your numbers match what you set in .wslconfig, you’re all set. If the old values persist, double-check that the file is saved in the correct location (%UserProfile%\.wslconfig) and that there are no syntax errors (e.g., missing GB or spaces around =).
Why does Docker Desktop on Windows initially allocate so few resources to WSL 2?
Docker Desktop relies on WSL 2’s default VM resource allocation, which is intentionally conservative to avoid using up all of your host’s resources. When WSL 2 was first introduced, Microsoft set modest defaults – 1 CPU and 1 GB of RAM – to ensure the VM wouldn’t starve the Windows host. This works fine for lightweight Linux tools, but it’s a disaster for resource‑hungry applications like SonarQube, which needs multiple cores and at least 2–4 GB of RAM for the Java heap alone. The limitation is not a bug; it’s a design choice that assumes most users will adjust the settings via .wslconfig if they need more power. Unfortunately, many people don’t know the file exists, leading to frustrating performance.