Gitlab: Операции Git чрезвычайно медленные на EC2.

Вопрос или проблема

РЕДАКТИРОВАТЬ: Оказалось, что это проблема 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

Также постоянно занимает около 2m7s.

Также:

Старый сервер:

--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...

Та же проблема с приоритетом IPv6 над IPv4 на EC2.
Я смог подтвердить это иначе, запустив ssh -Tvvv [email protected] (вставьте ваш собственный проблемный URL) и проверяя строки, где это было медленно.

debug1: Connecting to gitlab.com [2606:4700:90:0:f22e:fbec:5bed:a9b9] port 22.
debug3: set_sock_tos: set socket 3 IPV6_TCLASS 0x48
debug1: connect to address 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22: Connection timed out
debug1: Connecting to gitlab.com [172.65.251.78] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.

Чтобы исправить проблему, я создал файл /etc/gai.conf со следующим содержимым:

# For sites which prefer IPv4 connections change the last line to
precedence ::ffff:0:0/96 100
...
# For sites which use site-local IPv4 addresses behind NAT there is
# the problem that even if IPv4 addresses are preferred they do not
# have the same scope and are therefore not sorted first. To change
# this use only these rules:
#
scopev4 ::ffff:169.254.0.0/112 2
scopev4 ::ffff:127.0.0.0/104 2
scopev4 ::ffff:0.0.0.0/96 14

См. https://askubuntu.com/questions/32298/prefer-a-ipv4-dns-lookups-before-aaaaipv6-lookups для происхождения содержимого этого файла.

Ответ или решение

Учитывая описание проблемы и собранные данные, вы столкнулись с задержкой в Git-операциях из-за предпочтительного выбора соединения через IPv6 на одной из ваших EC2-инстанций. Это приводит к тайм-ауту при попытке подключения через GitLab, прежде чем сервер переключается на IPv4, который работает корректно.

Теория

Проблемы с производительностью при работе с Git на EC2 могут возникать по множеству причин, таких как перегруженный сетевой трафик, узкие места в конфигурации сервера, или некорректные настройки сети. В данном случае проблема связана с приоритетом использования протокола IPv6 над IPv4. В корпоративных средах, где IPv4 по-прежнему доминирует, а поддержка IPv6 может быть ограниченной, такие проблемы обретают особую актуальность.

Когда система настраивается для использования IPv6, сначала пробуется установить соединение через этот протокол. Если сервер назначения не оптимизирован или не принят для работы с IPv6, это может привести к значительным задержкам, так как каждый запрос будет ожидать тайм-аута перед переключением на IPv4.

Пример

Пример из текста проблемы показывает, как на более новой инстанции происходит задержка при выполнении команды git pull. При использовании команд для анализа производительности команды git, выяснилось, что система сначала пытается подключиться к серверу через IPv6, что приводит к ожиданию тайм-аута. Только после этого происходит успешное подключение через IPv4, но вся операция уже оказывается значительно замедленной.

Применение

Для устранения этой проблемы, необходимо изменить предпочтения подключения, чтобы система сначала использовала IPv4. Это достигается за счёт редактирования конфигурационного файла gai.conf, который управляет предпочтениями использования адресов сети в Linux.

Вы можете создать или изменить файл /etc/gai.conf с добавлением следующего содержимого:

# Для сайтов, предпочитающих соединения IPv4, измените последнюю строку
precedence ::ffff:0:0/96 100
...
# Для сайтов, использующих site-local IPv4 адреса за NAT, используйте эти правила:
scopev4 ::ffff:169.254.0.0/112 2
scopev4 ::ffff:127.0.0.0/104 2
scopev4 ::ffff:0.0.0.0/96 14

Изменения в данном файле установят приоритет для использования IPv4 по умолчанию, что должно устранить задержки из-за тайм-аутов при попытке соединения через IPv6.

Заключение

Важность правильной сетевой настройки в облачных средах, таких как AWS EC2, сложно переоценить. Проблемы с производительностью сетевого соединения могут быть вызваны некорректными предпочтениями протоколов и, как последствия, привести к значительным задержкам в работе критических систем. Предоставленное решение фокусируется на изменении предпочтений сетевого протокола, что позволяет минимизировать такие задержки и оптимизировать рабочий процесс. Настройка правильного порядка протоколов в современных системах гарантирует не только высокую скорость работы, но и повышает надежность и устойчивость ИТ-инфраструктуры.

Такой подход универсален и может быть применён к разным конфигурациям, если IPv6 не поддерживается полностью или присутствуют другие ограничения. Важно регулярно пересматривать и обновлять конфигурации систем, чтобы они соответствовали текущим потребностям и возможностям сети, что обеспечит максимально эффективную и бесперебойную работу ваших ИТ-сервисов.