search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.38k stars 819 forks source link

WSL2 git is slow from gitlab #6602

Closed golkedj closed 4 months ago

golkedj commented 3 years ago

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

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:

therealkenc commented 3 years ago

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 commented 3 years ago

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

therealkenc commented 3 years ago

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

On a lark, total WAG experiment, try:

$ sudo ifconfig eth0 mtu 1350
$ git clone ....
golkedj commented 3 years ago

@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 commented 3 years ago

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

$ sudo ip link set dev eth0 mtu 1350
golkedj commented 3 years ago

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 git@gitlab.com: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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@JensLincke That does not seem to help in my case

therealkenc commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

sudo ifconfig eth0 mtu 1350 up

Actticus commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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

huangzl97 commented 1 year ago

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 https://github.com/microsoft/WSL/issues/5420#issuecomment-646479747 to prevent wsl overwriting your resolve.conf file

KTanAug21 commented 1 year ago

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 commented 1 year ago

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[bot] commented 4 months ago

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!