GIT pull time out?

Question

Eu configurei recentemente uma pequena VM de controle de revisão turnkeylinux (que tem cerca de 256MB de RAM), e estou tentando clonar um dos repositórios que eu enviei para ele. É muito rápido para empurrar para (via ssh), mas é extremamente lento para puxar.

Veja o que recebo quando deixo o SSH expirar:

$ git pull
[email protected]'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

Eu tentei o clone assim:

> mkdir myProj
> cd myProj
> git init
> git remote add origin git+ssh://[email protected]/srv/repos/git/myProj
> git pull

Quando eu emito o comando pull, ele chega a 50% quase instantaneamente e depois pára. Ele se arrasta lentamente mais alguns por cento (uma tentativa chegou a 66%) e depois morre se for deixado o tempo suficiente.

Este repositório é pequeno com apenas algumas revisões até o momento. Meu repositório principal é muito maior e também será inutilizável, a menos que esse problema seja identificado.

Alguma idéia do que poderia estar causando a lentidão súbita?

Atualizar

Acabei de confirmar que a VM está lenta quando conectada usando o protocolo git: // também. Portanto, não pode ser um problema com o ssh. Atualizando o título da pergunta de acordo.

    

Answer 1

Você é capaz de clonar localmente na VM usando uma URL do repositório de file: ?

git clone file:///srv/repos/git/myProj /tmp/myProj-clone

O protocolo file: força as operações locais a usar um protocolo muito próximo do protocolo inteligente normal usado pelos git: / ssh: / smart- http: URLs remotos. Especificamente, ele usa um protocolo baseado em pacotes em vez de aproveitar a otimização normal para operações locais (hardlinking / copying de objetos de repositório).

Você pode não ter memória suficiente para o servidor gerar o pacote necessário para sua operação de recepção. Ao fazer um teste, o clone / pull local, baseado em file: , exercerá os recursos de geração de pacote de sua VM sem arrastar nenhum componente de rede para confundir o problema.

Existem várias variáveis de configuração que controlam a geração de pacotes :

• pack.window
• pack.depth
• pack.windowMemory
• pack.deltaCacheSize
• pack.deltaCacheLimit

Você pode ajustar seu repositório para gerar seus pacotes de maneira menos intensiva em memória (a eficiência de empacotamento provavelmente sofrerá como resultado).

Meu palpite é que 256MB (para sistemas operacionais e aplicativos?) é muito pequeno para esperar que (potencialmente) aplicativos com muita memória (como as operações de pacote do Git) funcionem rapidamente ou até mesmo corretamente.

    

Answer 2

Faça o login em 1.2.3.4 e cd no seu git repo e faça 'git reempack'; tente um puxão e veja se isso ajudou.

    

Answer 3

Tente desativar o descarregamento de segmentação TCP no servidor e > ethtool -k eth0 tso off

    

Answer 4

Pode ser que 256 MB acabem tendo pouca memória se você não tiver (o suficiente) swap e o OOM Killer entrar em ação. Você verificou os logs do sistema VM em busca de programas mortos? Qual é o tamanho do repositório no disco (o diretório .git para repositório não nu)?

Observe que o git é implementado para que o maior objeto (por exemplo, uma imagem ISO) no repositório esteja disponível na memória simultaneamente como dados descompactados e [git] compactados para dados a serem transferidos pela conexão ( transferência de dados git pack). Um único blob binário de 200MB strongmente compactado (por exemplo, um vídeo H.264) incluído no repositório fará com que o buscador / pull / clone dessa máquina consuma no mínimo cerca de 400MB de memória. Se o seu sistema tiver apenas 256MB para todo o sistema, você precisará de cerca de 140MB extras para o git, além de toda a memória exigida pelo sistema operacional da troca. Com espaço de troca suficiente, funcionará, mas será muito lento.

O Git é altamente otimizado para sistemas que podem manter pelo menos 10 objetos maiores armazenados no repositório na RAM. Um sistema com apenas 256MB de memória é suficiente se você lida com uma grande coleção de arquivos pequenos (por exemplo, kernel do Linux), mas vai parar para trocar se você tiver um único arquivo enorme. Para o caso de muitos arquivos pequenos, o requisito de memória parece estar em torno de 160 bytes vezes o número de objetos no repositório. Para ter uma ideia sobre a contagem de objetos, execute git count-objects -v e calcule a soma de count e in-pack . Quanto mais você tiver in-pack , menos git ocupará espaço em disco.

Se você quiser usar o git para um projeto que possui arquivos binários enormes e sua máquina de repositório git é limitada à memória, siga o desenvolvimento git para "objetos soltos".

Fonte: link