If you’re running Windows Subsystem for Linux on a system with 8GB of RAM or less, you’ve probably experienced your computer grinding to a halt when WSL is running. Your machine becomes sluggish, Chrome tabs start crashing, and Task Manager shows a process called “vmmem” consuming most of your memory.
The good news? You can configure WSL to work brilliantly even on low-memory systems. This guide shows you exactly how to set up WSL for optimal performance when RAM is limited.
Before progressing, you should consider more memory, if you can. The below will still be useful, but you can change the memory to a higher number.
Why WSL Consumes So Much Memory
By default, WSL allocates either 50% of your total RAM or 8GB, whichever is smaller. On older Windows builds (before 20175), it could grab up to 80% of your RAM. If you only have 8GB total, that means WSL might try to use 4GB, leaving Windows with barely enough to run.
The vmmem process you see in Task Manager represents all resources consumed by WSL’s virtual machine. Without proper configuration, it will happily consume all available memory.
The Perfect .wslconfig for 8GB Systems
The solution is creating a .wslconfig file that tells WSL exactly how much memory it can use. Here’s the optimal configuration for systems with 8GB total RAM:
[wsl2]
# Limit memory to 2GB (leaving 6GB for Windows)
memory=2GB
# Use 2 virtual processors
processors=2
# Disable unused swap space
swap=0
# Enable gradual memory reclaim
[experimental]
autoMemoryReclaim=gradualWhy These Settings Work
Memory=2GB: This might seem restrictive, but it’s actually generous for most development work. Basic web development, running a few Docker containers, or compiling code typically uses 1-1.5GB. Setting it to 2GB leaves Windows with 6GB, which prevents the system-wide slowdowns.
Processors=2: Unless you’re doing intensive compilation work, 2 CPU cores are sufficient for WSL. This prevents CPU contention between Windows and WSL.
Swap=0: On systems with only 8GB RAM, swap space often causes more problems than it solves. SSDs have limited write cycles, and swap thrashing creates noticeable slowdowns. Better to stay within your memory limits than rely on swap.
autoMemoryReclaim=gradual: This experimental feature allows WSL to return unused memory to Windows automatically, rather than holding onto it indefinitely.
Alternative Configurations by Use Case
For Docker Desktop Users (4GB Total RAM Available)
If you’re primarily using WSL for Docker Desktop, you can work with even tighter constraints:
[wsl2]
memory=1.5GB
processors=2
swap=0
localhostForwarding=trueDocker Desktop with 1.5GB can comfortably run 2-3 lightweight containers. A PostgreSQL database and a Node.js API server, for example, will happily coexist within these limits.
For Development With IDEs (Heavy Workloads)
If you’re running VS Code or IntelliJ alongside WSL, you need more breathing room:
[wsl2]
memory=3GB
processors=4
swap=2GBThis configuration gives WSL enough resources for intensive development work whilst still leaving 5GB for Windows and your IDE. The small swap space acts as overflow protection.
For Basic Terminal Work
If you mainly use WSL for command-line tools, scripts, and Git operations:
[wsl2]
memory=1GB
processors=2
swap=0This minimal configuration is perfect for SSH connections, running build scripts, or basic system administration. It leaves the maximum possible RAM for Windows applications.
How to Create Your .wslconfig File
Step 1: Open PowerShell or Command Prompt
Step 2: Run this command to create the file:
notepad "$env:USERPROFILE\.wslconfig"Step 3: Paste your chosen configuration
Step 4: Save the file and close Notepad
Step 5: Shut down all WSL instances:
wsl --shutdownStep 6: Start WSL again by opening Ubuntu (or your preferred distribution)
Verifying Your Settings Work
Once WSL restarts, you can verify the memory limit is applied by running this command inside your WSL distribution:
free -hThe output should show your configured memory limit. For example, with memory=2GB, you should see approximately 2GB total memory.
You can also check Task Manager in Windows. The vmmem process should now stay well below your configured limit, even when WSL is under load.
Common Problems and Solutions
WSL Still Using Too Much Memory
If vmmem still consumes more memory than expected after configuring .wslconfig:
- Check the file is saved in the correct location (
C:\Users\YourUsername\.wslconfig) - Ensure you’ve fully shut down WSL with
wsl --shutdown - Verify the file doesn’t have a hidden .txt extension (Windows sometimes adds this)
- Check for BOM (Byte Order Mark) issues by recreating the file using PowerShell instead of Notepad
Applications Running Out of Memory
If your applications are crashing with “out of memory” errors, you’ve set the limit too low. Gradually increase the memory allocation by 512MB until you find the sweet spot between performance and stability.
Slow Performance After Limiting Memory
Counter-intuitively, limiting WSL’s memory often improves overall system performance. If you’re experiencing slowdowns, the issue is probably elsewhere:
- Check if swap is enabled and causing disk thrashing (set
swap=0to disable) - Monitor your total system memory usage – Windows itself might be the bottleneck
- Consider whether you have too many browser tabs or applications open
Advanced Optimisations for 4GB Systems
If you’re trying to run WSL on a system with only 4GB of total RAM, standard configurations won’t work well. Here’s what actually works:
[wsl2]
memory=1GB
processors=2
swap=0
kernel=C:\\wsl2\\kernelAdditionally, you’ll need to:
- Use a lightweight WSL distribution (Alpine Linux rather than Ubuntu)
- Close all unnecessary Windows applications before starting WSL
- Disable Windows services you don’t need
- Consider using WSL 1 instead of WSL 2 for some workloads (it uses less memory but has slower file I/O)
Monitoring Memory Usage Over Time
To understand whether your configuration is working, monitor memory usage during typical workloads:
In Windows (PowerShell):
Get-Process vmmem | Format-Table Name, @{Name="Memory (MB)";Expression={$_.WorkingSet / 1MB -as [int]}}In WSL:
watch -n 5 free -hThis displays memory usage every 5 seconds, helping you identify whether you’ve allocated too much or too little.
When to Consider Upgrading RAM
Whilst these configurations make WSL usable on low-memory systems, there are scenarios where upgrading RAM is the better solution:
- Running multiple Docker containers simultaneously
- Machine learning or data science work
- Large-scale compilation projects
- Running databases alongside multiple services
For serious development work, 16GB is the comfortable minimum. But until you can upgrade, these configurations will help you get the most from what you have.
Real-World Performance Tests
I tested these configurations on an 8GB laptop running Windows 11 with WSL 2 Ubuntu. Here’s what worked:
Configuration: memory=2GB, processors=2, swap=0
- Running VS Code with WSL remote: ✓ Smooth
- Docker container (PostgreSQL + Node.js API): ✓ Worked perfectly
- Git operations and Node.js builds: ✓ No issues
- Chrome with 10+ tabs + WSL: ✓ Acceptable performance
Configuration: memory=1.5GB (for Docker only)
- Two lightweight containers: ✓ Worked well
- Three containers with databases: ✗ Started swapping, slow
- VS Code remote: ✗ Too tight for IDE work
The sweet spot for general development on 8GB systems is definitely 2GB allocated to WSL. It balances performance with leaving enough RAM for Windows.
Further Reading
For more information about WSL memory management:
- Understanding vmmem and why it consumes so much memory
- Microsoft’s official WSL configuration documentation
Summary
Running WSL on a low-memory system doesn’t have to be painful. The key is setting aggressive but realistic memory limits through .wslconfig. Start with 2GB for systems with 8GB total RAM, adjust based on your workload, and monitor performance to find your optimal configuration.
Remember: limiting WSL’s memory isn’t about hobbling it – it’s about ensuring your entire system runs smoothly. A well-configured 2GB WSL instance will outperform an unconfigured one fighting Windows for resources.