Недавно я установил небольшую виртуальную машину контроля версий Turnkeylinux (которая имеет около 256 МБ ОЗУ) и пытаюсь клонировать один из репозиториев, которые я к ней подтолкнул. Он очень быстро отправляется (через ssh), но очень медленно загружается.
Вот что я получу, если оставлю это до истечения времени ожидания SSH:
$ git pull
andrewm@1.2.3.4's password:
remote: Counting objects: 403, done.
Read from remote host 1.2.3.4: The connection was aborted
fatal: The remote end hung up unexpectedly
fatal: early EOF
Я попытался клонировать так:
> mkdir myProj
> cd myProj
> git init
> git remote add origin git+ssh://andrewm@1.2.3.4/srv/repos/git/myProj
> git pull
Когда я запускаю команду pull, она почти мгновенно достигает 50%, а затем останавливается. Он медленно продвигается вперед еще на несколько процентов (одна попытка достигла 66%), а затем в конечном итоге умирает, если оставить его достаточно долго.
Это репо крошечное, с небольшими изменениями. Мое основное репо намного больше и будет непригодным для использования, если эта проблема не будет выявлена.
Есть идеи, что могло вызвать внезапное замедление?
Я только что подтвердил, что виртуальная машина работает медленно при подключении по протоколу git: //. Следовательно, это не может быть проблемой с ssh. Соответственно обновите заголовок вопроса.
Войдите в 1.2.3.4, перейдите в репозиторий git и выполните «git repack»; затем попробуйте потянуть и посмотрите, помогло ли это.
Можете ли вы клонировать локально на виртуальной машине с помощью file: URL репозитория протокола?
git clone file:///srv/repos/git/myProj /tmp/myProj-clone
В file: протокол заставляет локальные операции использовать протокол, который очень близок к обычному интеллектуальному протоколу, используемому git:/ssh:/умная-http: удаленные URL-адреса. В частности, он использует протокол на основе пакетов вместо использования преимуществ обычной оптимизации для локальных операций (жесткие ссылки / копирование объектов репозитория).
У вас может не хватить памяти, чтобы сервер мог сгенерировать пакет, необходимый для операции извлечения. Делая пробное, местное, file:-based clone / pull будет использовать возможности генерации пакетов вашей виртуальной машины без перетаскивания каких-либо сетевых компонентов, чтобы запутать проблему.
Есть несколько переменные конфигурации которые управляют генерацией пакетов:
Возможно, вы сможете настроить свой репозиторий для создания пакетов с меньшим объемом памяти (хотя в результате, вероятно, пострадает эффективность упаковки).
Я предполагаю, что 256 МБ (для ОС и приложений?) Слишком мало, чтобы ожидать (потенциально) требовательных к памяти приложений (таких как операции пакета Git) для быстрой или даже правильной работы.
Попробуйте отключить разгрузку сегментации TCP на сервере-> ethtool -K eth0 tso off
Может случиться так, что 256 МБ в конечном итоге будут занимать мало памяти, если у вас не будет (достаточно) подкачки, и сработает OOM Killer. Вы проверили журналы системы виртуальной машины на наличие убитых программ? Насколько велик репозиторий на диске ( .git каталог для не голого репозитория)?
Обратите внимание, что git реализован таким образом, что самый большой объект (например, образ ISO) в репозитории должен быть доступен в памяти одновременно в виде распакованных и [git] сжатых данных для данных, передаваемых по сети (передача данных git pack). Один сильно сжатый двоичный BLOB-объект размером 200 МБ (например, видео H.264), включенный в репозиторий, заставит выборку / извлечение / клонирование с этой машины потреблять минимум около 400 МБ памяти. Если в вашей системе всего 256 МБ для всей системы, вам понадобится дополнительно около 140 МБ для git плюс вся память, необходимая ОС из подкачки. При наличии достаточного места для подкачки он будет работать, но будет очень медленно.
Git сильно оптимизирован для систем, которые могут хранить как минимум около 10 самых больших объектов, хранящихся в репозитории в оперативной памяти. Системы с объемом памяти всего 256 МБ вполне достаточно, если вы имеете дело с большой коллекцией небольших файлов (например, ядро Linux), но она будет работать, чтобы остановить обмен, если у вас есть хотя бы один огромный файл. Для случая с большим количеством небольших файлов потребность в памяти примерно в 160 байт превышает количество объектов в репозитории. Чтобы получить представление о количестве объектов, запустите git count-objects -v и вычислить сумму count и in-pack. Чем больше у вас есть in-pack тем меньше git занимает дискового пространства.
Если вы хотите использовать git для проекта с огромными двоичными файлами и ваша машина с репозиторием git ограничена по памяти, следуйте инструкциям по разработке git для "свободных объектов".
Источник: http://git.661346.n2.nabble.com/pack-operation-is-thrashing-my-server-td684437.html