2013-07-24 34 views
6

Khi cố gắng để sao chép một repo lớn (~ 700MB) trên https, git không thành công với:gitlab: git clone https với Repos lớn không

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

bản sao qua ssh hoạt động:

c:\git-projects>git clone [email protected]: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. 

Cloning kho nhỏ hơn với https cũng hoạt động:

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. 

Tôi đã điều chỉnh một số thông số nhưng không thành công:

/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 

Chúng tôi muốn sử dụng git clone https, vì công cụ studio trực quan cho git vẫn chưa triển khai ssh.

Trên máy chủ là hai quy trình, tải CPU đi tới 100% sau một thời gian, sau đó các quy trình được chấm dứt.

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

Kính trọng, 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: [email protected]: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 
+0

Chấm dứt bằng cái gì? oom-killer? ulimit? Thứ gì khác? –

+0

kích thước vùng tmp và RAM của bạn là bao nhiêu? –

+0

tmp là 2GB, ulimit là không giới hạn, không có quá trình bị giết trong syslog – mawl

Trả lời

5

này được báo cáo trong issue 3079: https nhân bản đòi hỏi một lượng lớn tài nguyên (CPU, nhưng chủ yếu là bộ nhớ) trên máy chủ GitLab, và hiện nay (GitLab 5.x) repo lớn.

Ngay cả GitLab 6.0 đi kèm với commits like 7ecebdd, đề cập đến thời gian chờ khi nhân bản lớn repo.

Tôi chưa thử nghiệm với GitLab 6, mặc dù (sẽ phát hành vào ngày mai).

+0

Tôi sẽ cập nhật lên 6.0 những ngày này, hãy xem liệu nó có sửa chữa hay không. – mawl

+0

6.0.1 có cùng vấn đề. Bây giờ nó chạy với unicorn không puma và mã lỗi là 502. – mawl

+0

@mawl Tôi đã thấy rằng chuyển đổi (http://stackoverflow.com/a/18398991/6309). Nhưng tôi không thấy 6.0.1. Tôi thực hiện theo các cam kết cho phiên bản 6.1 sắp tới. – VonC

1

Cân nhắc triển khai plugin chunking cho nginx, chẳng hạn như HttpChunkinModule.

Cá nhân tôi chưa triển khai ở trên nhưng có một khách hàng có vấn đề tương tự.

Trong trường hợp của họ, vấn đề là ở phía khách hàng, nơi chúng ta cần phải hướng dẫn các nhà phát triển để sử dụng các tinh chỉnh sau để git config địa phương của họ:

git config http.postBuffer 524.288.000 #set 500MB

Ở trên sẽ chỉ cho phép các yêu cầu http liên quan đến git lớn hơn ở phía máy khách (chúng tôi có rất nhiều bộ nhớ ở phía máy chủ).

+0

Các HttpChunkinModule không còn cần thiết nếu bạn đang sử dụng nginx> 1.3.8 http://wiki.nginx.org/HttpChunkinModule – spuder

+0

Tôi đã có lỗi tương tự khi đẩy đến một máy chủ https, sửa chữa này giải quyết được vấn đề, cảm ơn. –

Các vấn đề liên quan