WSL2 git is slow from gitlab

[golkedj]

Environment

Windows build number: [Version 10.0.19041.804]
Your Distribution version: [Ubuntu 20.04]
Whether the issue is on WSL 2 and/or WSL 1: [Linux version 4.19.128-microsoft-standard (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Tue Jun 23 12:58:10 UTC 2020]

Steps to reproduce

• Launch Ubuntu for WSL2
• Install and run speed test: https://www.speedtest.net/apps/cli
• Attempt to clone a git repository within the \\wsl$\Ubuntu\home\<user> directory
• Observe that gits reported network performance is far under the systems available network performance

Expected behavior

Git clones the repository in a timely manner with reasonable network speeds for the network you are on

Actual behavior

Git takes extremely long to finish the clone command and is operating well below the network thresholds.

This issue is is the worst when running git operations on repositories that are located on Gitlab (all repositories, private, public, etc). When interacting with Gitlab I see speeds <= ~80 KiB/s. When checking out from Github I see speeds >= 1 MiB/s. When interacting with either Gitlab or Github using windows git.exe commands I see speeds >= 20 MiB/s. I have also ran a speed test on my WSL2 Ubuntu instance via the command line tool and am getting ~200 Mbpsdownload and~20 Mbpsupload. Furthermore, all of my repositories are within\wsl$\Ubuntu\home\golkedj` and therefore should not be experiences I/O performance issues based on what I have read in this thread and other threads.
I am convinced that this issue only recently starting presenting itself because I have been interacting with this repository for several months with this exact same WSL2 Ubuntu instance and have noticed no issues at all until recently when I was unable to do anything with this repository within a reasonable amount of time. For example when I first set up this WSL2 Ubuntu instance I cloned this repository without issue, but now a fresh clone of it is taking several hours to complete (I have not actually been able to wait long enough for it to complete successfully).

I currently worked around this issue by using wsl.exe after modifying the core.autocrlf setting to input but this is not a feasible workaround due to the number of repositories I work with daily and the need to be able to run the WSL2 git command for them for consistency.

Performance details:

• Gitlab clone with WSL Ubuntu's git command:
  • Receiving objects: 16% (553/3435), 268.01 KiB | 34.00 KiB/s
• Github clone with WSL Ubuntu's git command:
  • Receiving objects: 100% (1034/1034), 487.62 KiB | 4.31 MiB/s, done.
• speed test results: https://www.speedtest.net/result/c/1b45ae1f-41ba-4e32-bea2-bc283632ccdf
• Gitlab clone with Windows git.exe command:
  • Receiving objects: 100% (3435/3435), 903.49 MiB | 19.56 MiB/s, done.
• Github clone with Windows git.exe command:
  • Receiving objects: 100% (434/434), 7.43 MiB | 13.19 MiB/s, done.

[therealkenc]

Gitlab clone with WSL Ubuntu's git command:
Receiving objects: 16% (553/3435), 268.01 KiB | 34.00 KiB/s

Can you please clarify the repro. Inside WSL Ubuntu, your options are cloning into /mnt/c/somewhere and /home/you/somewhere (contrast \\wsl$\Ubuntu\somewhere). Or post a screencap for context.

[golkedj]

@therealkenc I am attempting to clone into /home/you/somewhere or equivalent (not /mnt/c/somewhere)

[therealkenc]

Okay, thanks. So presumably it is slow into /anywhere.

On a lark, total WAG experiment, try:

$ sudo ifconfig eth0 mtu 1350
$ git clone ....

[golkedj]

@therealkenc Which package should ifconfig come from?

golkedj@DESKTOP-UQQ4025:~/tmp$ sudo ifconfig eth0 mtu 1350
[sudo] password for golkedj:
sudo: ifconfig: command not found
golkedj@DESKTOP-UQQ4025:~/tmp$ sudo apt install ifconfig
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package ifconfig

It looks like ifconfig has been deprecated and replaced with ip, however I am not familiar enough with either to be able to convert your example command to a new ip command. Source: https://unix.stackexchange.com/questions/145447/ifconfig-command-not-found#:~:text=You%20were%20probably%20looking%20for,ip%20from%20the%20package%20iproute2%20.

[therealkenc]

sudo apt install net-tools for ifconfig. For ip (via iproute2 package), it looks like:

$ sudo ip link set dev eth0 mtu 1350

[golkedj]

It is still stuck with a KiB/s speed.

golkedj@DESKTOP-UQQ4025:~/tmp$ sudo ip link set dev eth0 mtu 1350
[sudo] password for golkedj:
golkedj@DESKTOP-UQQ4025:~/tmp$ git clone [email protected]:some-repository.git
Cloning into 'some-repository'...
remote: Enumerating objects: 240, done.
remote: Counting objects: 100% (240/240), done.
remote: Compressing objects: 100% (130/130), done.
Receiving objects:  16% (553/3435), 4.80 MiB | 51.00 KiB/s0 KiB/s

[therealkenc]

Was worth a try, thanks. You are variation #4901 but can have your own landing zone, given variable gitlab has come up a few times and doesn't have a good explanation.

[golkedj]

For me I do not think it is a network issue as mentioned in #4901. I ran a speed test via WSL and the speed test CLI and that gave me extremely good numbers. Something else is going on here like throttling for specific things and/or slowdown due to I/O performance. I provided the speed test results in the issue description.

[JensLincke]

I had a similar issue with git performance under wsl2 and browsing other issues stumbled upon #6585.

I replace the default /etc/resolve.conf with

nameserver 8.8.8.8

And after this my "git pull" was pretty fast again. The problem was that resolving names the did not exist seems to be problematic when there is a VPN connection hanging around...

[golkedj]

@JensLincke That does not seem to help in my case

[therealkenc]

That does not seem to help in my case

Yes, you are seeing a crazy low bitrate (34.00 KiB/s). DNS related git "slowness" manifests as an unholy pause while the resolver sorts itself (if it does at all), but once the IP address has been resolved, the download proper proceeds at pace.

[golkedj]

Is there any workaround for this? I'm contemplating completely abandoning using WSL2 for development and switching back to a pure Windows development environment setup. However, I really do enjoy the WSL2 experience, other than this specific issue

[benhillis]

We have a fix for this incoming, but in the meantime this should get things working:

sudo ifconfig eth0 mtu 1350 up

[Actticus]

We have a fix for this incoming, but in the meantime this should get things working:

sudo ifconfig eth0 mtu 1350 up

Hi. Whats about fix? sudo ifconfig eth0 mtu 1350 up doesn't worked for me :(

[Housi]

This looks like more general networking issue within WSL. When connected to VPN all downloads get stuck or are super slow at best. I've checked alternative protocols, and it seems that OpenVPN (both TCP and UDP), works well. ExpressVPN's Lightway and IKEv2 don't.

[tchafack]

I was stuck on a "git push"
I close and open back WSL and I could push instantly

[huangzl97]

I had a similar issue with git performance under wsl2 and browsing other issues stumbled upon #6585.

I replace the default /etc/resolve.conf with

nameserver 8.8.8.8

And after this my "git pull" was pretty fast again. The problem was that resolving names the did not exist seems to be problematic when there is a VPN connection hanging around...

It works for me.
also remember to follow this comment #5420 (comment) to prevent wsl overwriting your resolve.conf file

[KTanAug21]

I had a similar issue with git performance under wsl2 and browsing other issues stumbled upon #6585.

I replace the default /etc/resolve.conf with

nameserver 8.8.8.8

And after this my "git pull" was pretty fast again. The problem was that resolving names the did not exist seems to be problematic when there is a VPN connection hanging around...

This works wonders! I was stuck cloning a repo at KiB/s, now it's MiB/s and completed! Thank you so much!

[ProximaB]

I have the same issue. cloning, fetching from wsl at Kb/s. Replacing the content of /etc/resolv.cong didn't work for me.
I am using Self Hosted Gitlab, FortiClient VPN and WSL2.
Funny thing that after invoking git pull, it surprisingly starts working at normal pace.
Edit: I think it may be somehow related to pausing system(sleep mode), git pull doesn't seems to help now

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!