gitlab: git clone https z dużych transakcji repo nie

Question

Podczas próby sklonowania dużą repo (~ 700 MB) przez HTTPS, git kończy się niepowodzeniem:

c:\git-projects>git clone https://git.mycompany.de/fs.git 
Cloning into 'fs'... 
Username for 'https://git.mycompany.de': mwlo 
Password for 'https://mwlo@git.mycompany.de': 
efrror: RPC failed; result=22, HTTP code = 500 
atal: The remote end hung up unexpectedly 

klon nad ssh działa:

c:\git-projects>git clone git@git.mycompany.de:fs.git 
Cloning into 'fs'... 
remote: Counting objects: 144564, done. 
remote: Compressing objects: 100% (30842/30842), done. 
remote: Total 144564 (delta 95360), reused 143746 (delta 94542) 
Receiving objects: 100% (144564/144564), 601.34 MiB | 1.33 MiB/s, done. 
Resolving deltas: 100% (95360/95360), done. 
Checking out files: 100% (4649/4649), done. 

Klonowanie mniejsze repozytoria https działa również:

c:\git-projects>git clone https://git.mycompany.de/git-test.git 
Cloning into 'git-test'... 
remote: Counting objects: 135, done. 
remote: Compressing objects: 100% (129/129), done. 
remote: Total 135 (delta 68), reused 0 (delta 0) 
Receiving objects: 100% (135/135), 18.77 KiB | 0 bytes/s, done. 
Resolving deltas: 100% (68/68), done. 

już manipulowane niektóre parametry, ale bez powodzenia:

/etc/nginx/nginx.conf 
worker_processes 2; # have two cpu's 
keepalive_timeout 120; 
client_max_body_size 3072m; 

/home/git/gitlab/config/gitlab.yml 
## Git settings 
    # CAUTION! 
    # Use the default values unless you really know what you are doing 
    git: 
    bin_path: /usr/bin/git 
    # Max size of a git object (e.g. a commit), in bytes 
    # This value can be increased if you have very large commits 
    max_size: 3221225472 # 3072.megabytes 
    # Git timeout to read a commit, in seconds 
    timeout: 120 

Chcielibyśmy skorzystać https git clone, jak wizualnych narzędzi studio do git nadal nie wdrożyły ssh.

Na serwerze są dwa procesy, obciążenie procesora wzrasta do 100% po pewnym czasie, a następnie procesy są kończone.

git pack-objects --revs --all --stdout --progress --delta-base-offset 

Pozdrawiam, Marco

---

System information 
System:   Debian 6.0.7 
Current User: root 
Using RVM:  no 
Ruby Version: 1.9.3p392 
Gem Version: 1.8.23 
Bundler Version:1.3.5 
Rake Version: 10.0.4 

GitLab information 
Version:  5.3.0 
Revision:  148eade 
Directory:  /home/git/gitlab 
DB Adapter:  mysql2 
URL:   https://git.mycompany.de 
HTTP Clone URL: https://git.mycompany.de/some-project.git 
SSH Clone URL: git@git.mycompany.de:some-project.git 
Using LDAP:  yes 
Using Omniauth: no 

GitLab Shell 
Version:  1.4.0 
Repositories: /home/git/repositories/ 
Hooks:   /home/git/gitlab-shell/hooks/ 
Git:   /usr/bin/git 

Answer 1

ta jest opisana w issue 3079: https klonowanie wymaga dużej ilości zasobów (CPU, ale przede wszystkim pamięć) na serwerze GitLab, a obecnie (GitLab 5.x) duże repozytorium.

Nawet GitLab 6.0 zawiera commits like 7ecebdd, wspominając o przekroczeniu limitu czasu podczas klonowania duże repozytorium.

Nie testowałem jednak z GitLab 6 (jednak powinien on zostać wydany jutro).

Answer 2

Rozważ wdrożenie wtyczki do wtyczki dla nginx, takiej jak HttpChunkinModule.

Osobiście nie wdrożyłem powyższego, ale mam klienta z podobnymi problemami.

W ich przypadku problem jest po stronie klienta, gdzie musimy instruować Devs użyć następującego uszczypnąć do lokalnego git config:

git config http.postBuffer 524288000 #set do 500MB

Powyższe pozwoli po prostu na większe żądania http związane z gitami po stronie klienta (mamy dużo pamięci po stronie serwera).