РЕДАКТИРОВАТЬ: Оказывается, это проблема Gitlab, но у меня до сих пор нет решения.
У меня странная ситуация с двумя из моих экземпляров AWS EC2. Они точно такие же с точки зрения ОС, региона и типа экземпляра (оба t3.micro), настроены одинаково (однако первый был настроен несколько месяцев назад).
Оба существуют в зоне доступности eu-central-1c, и оба работают в одном репозитории git. Обе версии также обновлены (CentOS 7.6.1810).
Старый сервер:
$ time git pull
Already up-to-date.
real 0m0.306s
user 0m0.034s
sys 0m0.016s
Более новый сервер:
$ time git pull
Already up-to-date.
real 2m7.547s
user 0m0.026s
sys 0m0.024s
Это также постоянно занимает около 2 м7 с.
Также:
Старый сервер:
--2019-04-09 10:52:03-- https://speed.hetzner.de/1GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1048576000 (1000M) [application/octet-stream]
Saving to: ‘1GB.bin’
100%[===============================================================>] 1,048,576,000 121MB/s in 6.5s
2019-04-09 10:52:10 (154 MB/s) - ‘1GB.bin’ saved [1048576000/1048576000]
Более новый сервер:
--2019-04-09 10:54:04-- https://speed.hetzner.de/1GB.bin
Resolving speed.hetzner.de (speed.hetzner.de)... 88.198.248.254, 2a01:4f8:0:59ed::2
Connecting to speed.hetzner.de (speed.hetzner.de)|88.198.248.254|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1048576000 (1000M) [application/octet-stream]
Saving to: ‘1GB.bin’
100%[===============================================================>] 1,048,576,000 130MB/s in 5.9s
2019-04-09 10:54:10 (170 MB/s) - ‘1GB.bin’ saved [1048576000/1048576000]
РЕДАКТИРОВАТЬ: я пытался использовать репозиторий GitHub вместо нашего GitLab, и оказалось, что это проблема GitLab. Что могло быть причиной того, что GitLab быстро реагировал на старый сервер, но не на другой?
РЕДАКТИРОВАТЬ 2: Попытка клонировать через HTTPS. На то, чтобы запросить мое имя пользователя, уходит 2 минуты.
Кроме того, подробный вывод по SSH:
$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git pull
trace: exec: 'git-pull'
trace: run_command: 'git-pull'
trace: built-in: git 'rev-parse' '--git-dir'
trace: built-in: git 'rev-parse' '--is-bare-repository'
trace: built-in: git 'rev-parse' '--show-toplevel'
trace: built-in: git 'ls-files' '-u'
trace: built-in: git 'symbolic-ref' '-q' 'HEAD'
trace: built-in: git 'config' '--bool' 'branch.#hidden#.rebase'
trace: built-in: git 'config' '--bool' 'pull.rebase'
trace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'
trace: built-in: git 'fetch' '--update-head-ok'
trace: run_command: 'ssh' '-p' '#hidden#' 'git@#hidden.tld#' 'git-upload-pack '\''/#hidden#/#hidden#.git'\'''
Обнаружена проблема с использованием подробного вывода.
Более новый сервер пытался связаться с сервером конечной точки git, используя IPv6, и ждал тайм-аута, прежде чем вернуться к IPv4 (который действительно работает).
$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone https://#hidden#/#hidden#/#hidden#.git
trace: built-in: git 'clone' 'https://#hidden#/#hidden#/#hidden#.git'
Cloning into '#hidden#'...
trace: run_command: 'git-remote-https' 'origin' 'https://#hidden#/#hidden#/#hidden#.git'
* Couldn't find host #hidden# in the .netrc file; using defaults
* About to connect() to #hidden# port 443 (#0)
* Trying x:x:x:x:x:x:x:x...
* Connection timed out
* Trying x.x.x.x...