GoogleCloudPlatform / artifact-registry-apt-transport

Apache License 2.0
10 stars 17 forks source link

apt install painfully slow to download a package #7

Open adaszko opened 2 years ago

adaszko commented 2 years ago

Hi 👋

I'm experiencing an issue with apt install (same with apt-get) whereby it's painfully slow to complete a simple apt install command. So much so that I wasn't able to complete a simple installation of a single package since yesterday. I'm using this sequence of commands on a Google Cloud VM:

curl https://europe-west6-apt.pkg.dev/doc/repo-signing-key.gpg | sudo apt-key add -
echo deb https://europe-west6-apt.pkg.dev/projects/radicle-services radicle-cli main | sudo tee -a /etc/apt/sources.list.d/radicle-registry.list
sudo apt update
sudo apt install radicle-cli

From what I see from strace, apt repeatedly timeouts on select() calls for the most part, idling most of the time.

What's curious, wget 'https://europe-west6-apt.pkg.dev/projects/radicle-services/pool/radicle-cli/radicle-cli_0.6.0_amd64_3662282cc3a7626852c69a4218499ab6.deb' downloads the file instantly.

adaszko commented 2 years ago

In case that matters, I'm running those command on a VM in the europe-north1-a zone.

ericdand commented 2 years ago

Thanks for the report. This is a recent issue (as of the last few weeks) that we're aware of and currently trying to reproduce consistently so we can figure out what's causing the slowdown. Thanks especially for the report that wget seems to work just fine; I'm starting to suspect some kind of strange interaction with apt is to blame.

ericdand commented 2 years ago

I've spent the better part of today trying to reproduce this in various ways, and I've found something very similar to your results:

  1. Running from within a Docker container makes it a lot worse; there might be something funny to do with how Docker containers share a network device with the OS that makes it worse.
  2. Retrieving artifacts via wget or curl always goes flawlessly (regardless of being in a Docker container), so this is definitely an apt-specific issue.
  3. The cause of the failure is the connection being closed before the transfer is complete, but apt doesn't seem to know that it's been closed; it always waits a good 30s (which I assume is its "inactive transfer" timeout) before retrying the transfer.

Though I've not been able to identify a bug in the apt code or a specific exchange of packets which always elicits the failure yet, I'm getting closer to a proper diagnosis.

remedycoin commented 2 years ago

For me it had something to do with running PIA VPN . I turned off the vpn and my apt update went blazing fast.

Ubuntu 22.10 Docker version 20.10.16, build 20.10.16-0ubuntu1

I have a hunch that editing the apt settings to IPv4 only might help. Good luck guys and gals!