对 gitlab 6.5 的 HTTPS 请求超时

Question

我这里有一个非常酷的 gitlab 设置:

• apache2.2.22-1ubuntu1.4
• gitlab 6.5(使用 mod_proxy 集成到 apache)
• unicorn v4.3.1(rails 网络服务器)
• 2MBit 向上/向下连接到互联网

但是，当执行“git clone”或“git pull”时，存储库大小 > 10 Mib 时会失败。

ubuntu~/Projects/git/myRepo(master|✔) % git pull 
Username for 'https://example.org': my.username@mydomain.de 
Password for 'https://my.username@mydomain.de@example.org': 
remote: Counting objects: 7798, done. 
remote: Compressing objects: 100% (4132/4132), done. 
fatal: The remote end hung up unexpectedlyiB | 222 KiB/s     
fatal: early EOF
fatal: index-pack failed 

它似乎能够复制大约8Mib 数据并最多运行大约 30 秒。该问题每次都会重现，并且一遍又一遍地显示出相同的故障迹象。

我读过: http://jinsucraft.wordpress.com/2013/01/08/when-github-git-clone-fails-with-early-eof-and-index-pack-failed/并尝试过:

git config --global http.postBuffer 524288000

在客户端无济于事。

有人知道什么可能导致这种情况吗？

Answer 1

此问题的原因可能是超时问题(或类似的限制，例如数据量):服务器端发生超时，从而关闭了 http 连接，导致客户端出现“early EOF”错误消息。此类超时可以在多个位置进行配置(我在这里列出它们是因为其他 Web 服务器可能有类似的设置，因此它们可能会提示您在哪里查看):

• Apache 的 Timeout确定连接被切断之前的绝对静默时间(即没有数据传输)。由于数据是连续接收的，所以这不是这里的问题。
• Apache mod_proxy 的 ProxyTimeout是对上述Timeout的专门设置。同样，由于它不是总请求时间的限制，因此这不是这里的问题。
• Apache 可以使用 LimitRequestBody 限制 POST 请求的大小;默认情况下没有限制，但这可能会因您的发行版配置而异
• gitlab 的 Unicorn configuration example建议超时 30 秒。这是绝对超时，例如每个请求时间超过 30 秒都将被终止。

增加 Unicorn 配置中的超时应该可以解决您的问题。请记住，并行请求的数量也受到 Unicorn 的限制。克隆大型存储库会阻止一个请求，但几乎不会导致 CPU 负载。如果您的 gitlab 服务器没有高流量，您应该考虑增加 worker_process 数量。

作为旁注:gitlab.yml 配置还提供了 git timeout ;此超时限制了 git 操作，例如计算多个提交的差异。它对克隆/拉取时的超时没有影响。