O Git não consegue empurrar com o erro 'sem memória'

Question

Estou usando a gitosis em um servidor com pouca memória, especificamente em torno de 512 MB. Quando eu tento empurrar uma pasta grande (por acaso é um backup de um telefone Android), recebo:

me@corellia:~/Configs/$ git push origin master

Counting objects: 18, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
fatal: Out of memory, malloc failed MiB | 685 KiB/s   
error: pack-objects died of signal 13
error: failed to push some refs to 'git@dagobah:Configs'

Estou pesquisando na Web e, em especial, encontrei: link bem como link mas estes don ' Pareceu-me ajudar por duas razões: 1) Eu não estou realmente fora de memória quando eu empurro. Quando eu corro 'top' durante o push, recebo:

24262 git       18   0 16204 6084 1096 S    2  1.2   0:00.12 git-unpack-obje   

Além disso, durante o envio se eu executar / head / meminfo, eu recebo:

MemTotal:       524288 kB
MemFree:        289408 kB
Buffers:             0 kB
Cached:              0 kB
SwapCached:          0 kB
Active:              0 kB
Inactive:            0 kB
HighTotal:           0 kB
HighFree:            0 kB
LowTotal:       524288 kB

Então, parece que eu tenho memória livre suficiente, mas na verdade ainda está falhando, e eu não sou o suficiente de um guru para descobrir o que está acontecendo. Eu agradeceria se alguém me desse uma mão aqui e me dissesse o que poderia estar causando esse problema, e o que eu posso fazer para resolvê-lo.

Obrigado!

EDITAR:

A saída da execução do comando ulimit -a :

scottj@dagobah:~$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 204800
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 204800
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

EDITAR :

Os objetos e tamanhos do git são:

313796  .git/objects/88/7ce48679f885af4c466d4ddccef9a9954a9de6
224276  .git/objects/18/261f6a52926a756c7ecb453e025d1f25937026
6248    .git/objects/63/a0b4e622c893d3dcc162052b43301030d0c86d
5608    .git/objects/a2/0c65987656cba591171549752eb97f0207fec8
2608    .git/objects/pack/pack-3be8300f69b67fa8fa687df84bbd9b8c96e86c8e.pack
28  .git/objects/pack/pack-3be8300f69b67fa8fa687df84bbd9b8c96e86c8e.idx
24  .git/objects/c9/8909563ec60369d69ac2d317af25a44c9fc198
24  .git/objects/5d/1f74bd9bc4c575a7eeec08d59916d9829068d1
24  .git/objects/53/edad79cb051f5e7864d9d3339fa59990ccfe2d
8   .git/objects/80/dd50c7a314950e5a1f56c0210b0a91f48ee792

    

Answer 1

É um pouco exagerado, mas experimente

git -c core.packedGitWindowSize=32m -c core.packedGitLimit=256m push origin master

Isso substitui alguns parâmetros que limitam o número de bytes mapeados de arquivos. Estes são os padrões usados para um sistema de 32 bits, os padrões de 64 bits são muito maiores. Estou especulando que você está usando um sistema de 64 bits, o que está fazendo com que o git use padrões muito grandes, mas existem restrições de recursos (talvez da execução em uma VM) que acionam o erro.

Esses parâmetros e valores de configuração vieram do link

    

Answer 2

Qual é o tamanho da maior bolha sendo empurrada para o repositório?

Você pode tentar executar um:

find .git/objects -type f -print0 | xargs -0 du -s | sort -rn | head

Estou olhando especificamente para esta mensagem do encadeamento da lista de discussão do git ao qual você está vinculado.

    

Answer 3

Em que plataforma / distribuição você está? Ubuntu, redhat, centos, etc ... Tanto para o cliente como para o servidor? Qual é o uso de memória no cliente que você está empurrando? Eu tive isso acontecer antes com pushs que abrangem um grande número de revisões. Eu sei que uma solução é incrementalmente empurrar suas alterações para o servidor, se possível. A outra solução é aumentar o uso de memória do kernel. Com algumas distribuições de kernel, existem configurações que impedem que o kernel seja alocado para um único processo:

Set Kernel Parameters
Modify the "/etc/sysctl.conf" file to include the lines appropriate to your operating system.
# Red Hat Enterprise Linux 3.0 and CentOS 3.x 
 kernel.shmmax = 2147483648
 kernel.shmmni = 4096
 kernel.shmall = 2097152
 kernel.shmmin = 1
 kernel.shmseg = 10

# semaphores: 
 semmsl, semmns, semopm, semmni kernel.sem = 250 32000 100 128
 fs.file-max = 65536

# Red Hat Enterprise Linux 4.0 and CentOS 4.x 
 kernel.shmmax = 536870912
 kernel.shmmni = 4096
 kernel.shmall = 2097152

Se o seu processo do git exceder os limites, o kernel irá matar o processo apesar da memória máxima reportada estar disponível no seu sistema.

Nota: tenha cuidado com estas configurações. Você provavelmente não quer usar as configurações nesse exemplo quando eu as tirei de um servidor em nosso ambiente.

Algumas notas extras para mencionar:

To Update and test kernel settings with sysctl, use following commands:

List current settings: sysctl -A|grep shm

sysctl -w kernel.shmmax=<value> to write in sysctl.conf
sysctl -p /etc/sysctl.conf to read/reload the values from sysctl.conf

Disable secure linux by editing the "/etc/selinux/config" file, making sure the SELINUX flag is set as follows.

SELINUX=disabled