Jenkins git插件 - 有时非常慢

Question

以下内容摘自 Jenkins 日志：

00:00:03.135  > git fetch --tags --progress [e-mail]:some_org/some_repo.git +refs/heads/*:refs/remotes/origin/*
00:03:49.659  > git rev-parse origin/master^{commit} # timeout=10

我对为什么会出现这个超时的情况感到困惑，因为在同一台机器上使用相同的用户运行git fetch只需要大约5到10秒的时间。

我正在使用最新版本的Git（截至本文撰写时为2.1.2），以及最新版本的git插件。

有何想法？

- JAR.JAR.beans

Answer 1

至少在我们的情况下，问题是git版本引起的。我们升级了从1.9到2.1.2版本，问题得到解决。当我第一次发布问题时，我错误地认为已经完成了升级。

- JAR.JAR.beans

Answer 2

注意：Git 2.2+（2014年11月）后，git fetch的速度应该再次提高。

请参见Jeff King（peff）的提交cbe7333。

引用：加快is_refname_available的速度。

我们的文件系统引用存储不允许D/F（目录/文件）冲突; 因此，如果“refs / heads / a / b”存在，则不允许存在“refs / heads / a”（反之亦然）。 这对于松散的引用来说是自然而然的，因为文件系统强制执行该条件。但是，对于打包的引用，我们必须自己进行检查。 我们通过迭代整个打包的引用命名空间并检查每个名称是否创建冲突来实现这一点。如果您有大量的引用，这非常低效，因为您最终会与引用树的无趣位进行大量比较（例如，我们知道在上面的示例中，“refs / tags”都是无趣的，但我们仍然检查其中的每个条目）。 相反，让我们利用打包引用作为trie的ref_entry结构存储的事实。当我们遍历树时，我们可以找到建议的refname的每个组件，并在前进时检查D / F冲突。对于深度N（即上面示例中的4）的refname，我们只需要访问N个节点。在每次访问时，我们可以对该级别的M个名称进行二进制搜索，总复杂度为O（N lg M）。 （“M”在每个级别上都不同，但我们可以将最坏情况的“M”作为边界）。 在将30,000个新引用提取到具有8.5百万个引用的存储库中的病态情况下，这将使运行“git fetch”的时间从数十分钟降至约30秒。 这也可能有助于我们检查松散引用的较小情况（在重命名引用时进行检查），因为我们可以避免与不相关的松散目录进行磁盘访问。 请注意，我们添加的测试乍一看似乎与t3210中已有的测试重复。但是，早期的测试不够健壮；它们在打开reflog的情况下运行，这意味着我们实际上根本没有测试is_refname_available！操作仍将失败，因为reflog将在文件系统中出现D / F冲突。要进行真正的测试，我们必须关闭reflog（但我们不想对整个脚本进行此操作，因为打开它们的目的是覆盖其他某些情况）。

- VonC