Вопросы Теги

Агрессивный git GC не работает с сигналом 99019 от пакетов-объектов? [Дубликат]

Попробуйте это сработало для меня. Добавьте эту зависимость в ваш файл build.gradle 

compile 'org.jbundle.util.osgi.wrapped:org.jbundle.util.osgi.wrapped.org.apache.http.client:4.1.2'
54
задан zoul 5 October 2011 в 11:27
поделиться

6 ответов

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

git config pack.windowMemory 10m
git config pack.packSizeLimit 20m

Возможно, вы захотите сделать то же самое в своем локальном репозитории. (Кстати, я полагаю, что ваш репозиторий очень большой или это машины с небольшой памятью - эти значения для меня очень низкие).

Для чего это стоит, когда при сбоях malloc при переупаковке очень больших репозиториев в прошлом, я также изменил значения core.packedgitwindowsize, core.packedgitlimit, core.deltacachesize, pack.deltacachesize, pack.window и pack.threads, но это звучит так, как будто вы не нужны другие варианты:)

94
ответ дан Mark Longair 18 August 2018 в 03:34
поделиться
  • 1
    Спасибо за настройки конфигурации, я раньше их не знал. Репозиторий содержит большой набор файлов PDF. Общий размер репозитория (включая каталог .git и отслеживаемые файлы) соответствует 1,1 ГБ. Поэтому я предполагаю, что это большой репозиторий ;-) – midtiby 30 January 2011 в 11:16
  • 2
    @MarkLongair: ты спас мой день, сэр! Я собирался запустить в магазин и купить обновление оперативной памяти: D – Andresch Serj 16 January 2013 в 15:38
  • 3
    @MarkLongair: Отличный ответ !!! Спасибо за такую ​​полезную информацию – nish 1 May 2014 в 10:42
  • 4
    Специально в Dreamhost мне пришлось использовать pack.windowMemory 10m pack.packSizeLimit 20m pack.deltacachesize = 20m pack.threads = 2 и core.deltacachesize = 20m core.packedgitlimit = 30m. Спасибо @MarkLongair – UrsoBranco 19 July 2017 в 13:37

У меня была такая же проблема на ubuntu 14.10 с git 2.1.0 в частном репозитории github.com. (Предполагается, что маршрутизатор Entreprise работает в разных сетях Wi-Fi, за исключением рабочего места). 

* GnuTLS recv error (-54): Error in the pull function.
* Closing connection 2jects:  31% (183/589)   
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header

Мое решение заключалось в том, что git clone с использованием ssh (я заранее установил ssh-ключи):

git clone https://github.com/USERNAME/REPOSITORYNAME.git

становится:

git clone git@github.com: USERNAME / REPOSITORYNAME.git

*: (Генерация ключа ssh)

ssh-keygen -t rsa -C "your_email_address_registered_with_github@domain.com"

Затем войдите в github, в настройках, импортируйте ssh-ключи и импортируйте его из ~ / .ssh / id_rsa.pub.

0
ответ дан arcol 18 August 2018 в 03:34
поделиться
  • 1
    Я слышал о корпоративных маршрутизаторах, занимающихся сканированием контента и удалением соединений для HTTP, но никогда HTTPS - не расшифровывает и не зашифровывает трафик HTTPS? – Rup 30 April 2015 в 14:33
  • 2
    Rup: Перед выходом в Интернет есть два маршрутизатора. На следующей неделе я буду точно проверять, как настроить эту конкретную компанию. Я проверял, так как это никуда не денется (любая другая сеть wifi), только в этой конкретной компании. – arcol 1 May 2015 в 15:33

Я решил проблему, выполнив следующие шаги.

  1. Получил репозиторий, извлеченный с сервера на мой локальный компьютер (используя необработанную копию поверх ssh)
  2. локальный репозиторий git repack -a -d --window-memory 10m --max-pack-size 20m
  3. Создал пустой сервер на сервере git init --bare
  4. Вытолкнул локальный репозиторий на сервер
  5. . Проверял, что можно клонировать репозиторий сервера
15
ответ дан eckes 18 August 2018 в 03:34
поделиться
  • 1
    Я рад слышать, что вы отсортированы, но я должен предупредить вас, что у вас снова будет такая же проблема, когда сервер решит переупаковать свой репозиторий. Лучше всего было бы установить параметры конфигурации в удаленном репозитории (например, как было предложено в моем ответе), чтобы при автоматической переупаковке вы все равно не исчерпали память. – Mark Longair 14 September 2011 в 16:17
  • 2
    Спасибо, это работа – VolArt 14 October 2017 в 17:16

Я использую git версии 1.7.0.4, и он принимает эту команду. Возможно, git версии 1.6 не принимает эту команду.

Попробуйте создать новый репозиторий с некоторыми случайными коммитами. Затем переустановите его с помощью этой команды.

1
ответ дан matthias.lukaszek 18 August 2018 в 03:34
поделиться
  • 1
    Вы говорите об этой команде? git repack -a -d --window-memory 10m --max-pack-size 100m – Flimm 4 October 2016 в 12:28

Не имея прямого доступа к репозиторию и, следовательно, неспособного выполнить переупаковку, выполнение мелкого клона, а затем постепенное извлечение, а увеличение глубины помогло мне. 

git clone YOUR_REPO --depth=1
git fetch --depth=10
...
git fetch --depth=100
git fetch --unshallow    //Downloads all history allowing to push from repo

Надеюсь, что он все равно может помочь кому-то.

18
ответ дан mmm 18 August 2018 в 03:34
поделиться
  • 1
    как последнее средство для большой работы, это действительно сработало. Благодарю. – Sajib Acharya 17 May 2016 в 13:12
  • 2
    git clone REPO --depth=1 все еще не удалось для меня с ошибкой remote: aborting due to possible repository corruption on the remote side. – Flimm 4 October 2016 в 13:12

Это не отвечает на вопрос, но кто-то может столкнуться с этим: переполнение может также завершиться неудачей на сервере, когда pack-objects завершается каким-то убийством памяти (например, используемым на Dreamhost): 

$ git clone project-url project-folder
Cloning into project-folder...
remote: Counting objects: 6606, done.
remote: Compressing objects: 100% (2903/2903), done.
error: pack-objects died of signal 9284.51 MiB | 2.15 MiB/s   
error: git upload-pack: git-pack-objects died with error.
fatal: git upload-pack: aborting due to possible repository corruption on the remote side.
remote: aborting due to possible repository corruption on the remote side.
fatal: early EOF
fatal: index-pack failed

В Dreamhost это, по-видимому, вызвано mmap. Код repack использует mmap для сопоставления содержимого некоторых файлов в память, а поскольку убийца памяти недостаточно умен, он учитывает mmapped-файлы как используемую память, убивая процесс Git, когда он пытается mmap создать большой файл.

Решение состоит в том, чтобы скомпилировать пользовательский двоичный файл Git с отключенной поддержкой mmap (configure NO_MMAP=1).

5
ответ дан zoul 18 August 2018 в 03:34
поделиться
  • 1
    Знаете ли вы, можно ли добавить NO_MMAP = 1 в существующую установку git? – Max Williams 3 November 2011 в 14:39
  • 2
    Я не думаю, что это выглядит как макрос препроцессора, который приводит к созданию другого кода. Но это просто мнение, я не исследовал его. – zoul 3 November 2011 в 15:29
Другие вопросы по тегам:

Похожие вопросы: