Performance issues in Warden on WSL2

[danni140c]

I already searched for "wsl" and "performance" in issues and discussions, I did not find anything that seemed relevant.

I am using Warden in WSL2 (Ubuntu 22.04) on Windows 10. The PC has an AMD Ryzen 7 3700X and 32GB RAM. I use Warden for Magento 2. Using Docker Desktop v4.28.0.

I (and my colleagues) experience very significant performance issues sometimes, while using Warden. WSL2 will become completely unresponsive, making it impossible to use Warden or anything else in WSL2. Sometimes WSL2 will start being responsive after some time (~20-40 minutes). Most often we need to restart WSL2.

When the issue occurs, it seems disk usage is very high. After restarting WSL2, disk usage will go back to normal. See attached image from Task Manager.

The issue often occurs when I start multiple Warden environments, usually already when I start a second or third environment. Sometimes it occurs with only a single running environment, though not as often as when starting multiple.

I (and my colleagues) previously used a different Docker setup for Magento 2, where I (and my colleagues) never had these issues. So I am wondering if this has something to do with Warden, or maybe it is just a WSL2 issue? I suspect the disk usage might be due to usage of swap, but that is just a guess.

Has anyone experienced this before? Do you have any ideas/tips? Any idea for tweaks that could improve performance?

Thank you in advance!

[danni140c]

If there is any relevant information I failed to provide, please let me know, and I will see if I can provide it.

[navarr]

I'm curious where your files are stored and how you're mounting and editing them. Could you please tell me a little bit about how thats setup?

[danni140c]

I store my files in the WSL2 distribution (Ubuntu 22.04), I store them at ~/projects/my-project-name.
I usually edit them with VS Code, using the WSL extension https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-wsl.

[danni140c]

So I do NOT store them on the Windows 10 file system, if that is what you were wondering.

[danni140c]

It seems to be mainly reading. Not so much writing.

[danni140c]

Disabling SBOM indexing in Docker Desktop, seems like it might have fixed the issue for me. EDIT: It did not fix it.
A colleague mentioned using a custom kernel helped with his issues https://github.com/Locietta/xanmod-kernel-WSL2.
Just leaving it here, in case someone else has similar issues and comes looking for a possible solution.
EDIT: Using the custom kernel is not a solution for me. When using the custom kernel, my db container will exit/die while importing a database.

[hardyjohnson]

@danni140c have you looked at the container level process numbers via htop or similar?

[danni140c]

@hardyjohnson I have not. Which numbers exactly do you mean?

[hardyjohnson]

Using something like warden shell command you should be able to log into your running containers and get a good idea of process level resource usage.

There could be any number of different ways to have contention (more than one process attempting to use the same shared resource, file, network, other), like mapping the composer cache directory to the same local path and running composer install from two environments.

Docker may also be reaching memory limits and needing to use swap space which would cause lots of reads (writes too). With multiple environments running you may be hitting a memory threshold here.

Other things that could cause excessive slowness are the use of debug containers, tracing, excessive logging, opcache settings especially could affect performance here.