我们的GitLab经常变慢

Question

过去几天，我们的GitLab（CE）经常运行缓慢。我们与詹金斯有一个关于CI的钩子。我们已经安装了OmniAuth的GitLab。我对此没有更多的想法，因为我们在实例中没有做任何新的事情。

我们是GitLab环境的新手。我们自2016年12月开始在GitLab工作，我们之前从未遇到过这类问题。我希望我能和你们一起解决这个问题。请帮助我解决问题。

按照下面的图片查看我们的Gitlab详细信息。

我怎样才能克服这个问题？

Answer 1

这些仅仅是一些没有保修的现有建议，但它们可能有助于指导您解决问题。

奥卡姆剃刀

您提到这些问题似乎刚刚开始。这意味着要查看非常第一的地方是在这些问题发生时可能发生的变化。如果您对基础架构进行了更改控制，请从那里开始。绝对确保在这些问题开始发生时没有人改变任何事情。检查日志中是否有可能已开始显示的警告。如果您的操作系统有安全日志或记录配置更改，请检查它们。如果您在环境中没有良好的可见性/审计能力，这可能很难，但如果您能够识别出在这些问题开始发生的同时发生变化的事情，那么这通常是您的问题

<强>特异性

通过它变慢来描述你的意思可能会有所帮助。这是一个特定的操作是否缓慢？还是一切活动？如果它是特定的东西，比如触发Jenkins工作，那么你可以开始在那里隔离你的搜索。

它还可以帮助您在服务器上运行top，以了解可能导致问题的原因。可能有一个特定的进程在机器上运行，主宰其他一切并占用所有资源。

<强>硬件

我要检查的第一件事是确保您的硬件配置符合＆＃39;硬件要求＆＃39;关于gitlab网站的指南： https://docs.gitlab.com/ce/install/requirements.html#requirements 根据您发布的内容，您的系统上的CPU和内存似乎已经足够数千名用户，因此我将假设这不是问题，但如果您确实有数千名用户，我将在此添加一些简要信息。您的磁盘配置（尺寸除外）未在上述信息中显示，因此我们不知道这是否足够。

我建议在服务器上运行vmstat（因为它的GitLab，我假设它在Linux上运行，因为他们不建议使用Windows安装）来获取有关内容的一些基本信息上。 vmstat命令将为您提供多列信息。在最左边应该有一列＆＃39; r＆＃39;。这是＆＃39;运行队列＆＃39;，或者等待在CPU上运行的进程数。如果该列中的值与系统所具有的核心数相比较大，则可能存在CPU瓶颈。下一栏＆＃39; b＆＃39;是被阻止的进程。如果这个很大，你可能没有CPU瓶颈。在右边，有CPU列：us，sy，id或这些行中的某些内容。这些列是CPU在应用程序代码（us），OS代码（sy）或等待（id）中花费时间的细分。我们中的高百分比数字通常表示您运行状况良好或者存在CPU瓶颈。 sy中的高百分比数字通常表示某种争用，可能是配置问题，例如为您拥有的CPU数量配置了太多的工作线程。 id中的高百分比数字通常表示系统要么做得不多，要么做得不多，因为它等待磁盘或外部数据库之类的东西。

所以，如果＆＃39; b＆＃39;和/或＆＃39; id＆＃39; vmstat输出中的列数较多，我们可能需要考虑是否存在I / O瓶颈。以下是一些关于评估Linux IO瓶颈的介绍性文章，可能有助于您确定是否是这种情况： https://bartsjerps.wordpress.com/2011/03/04/io-bottleneck-linux/ http://www.linux-mag.com/id/2001/ 这些文章应该让您指出正确的方向，以帮助您确定您的磁盘是否足够快。

有一点需要注意的是，如果您看到了似乎是CPU瓶颈（高r值，高美值），请确保这种情况对您拥有的用户数量有意义。 CPU瓶颈可能导致虚拟化问题，或者某些操作系统问题导致CPU性能不佳，而不仅仅是CPU硬件本身不足。

<强>拓扑

我在上面链接的gitlab要求中提到的一件事是，不建议在与GitLab本身相同的盒子上运行GitLab runner。对于使用GitLab的任何CI软件，我都会这样说。如果你在与GitLab本身相同的盒子上运行GitLab Runner或Jenkins，你应该考虑将它们移到他们自己的硬件上。

如果您有数千名用户，您可能希望自己与GitLab联系并咨询如何让企业级集群站起来以及看起来如何。有些人是特定硬件配置的专家，对于非常大的GitLab安装有意义，而我不是其中之一。但是，如果您没有大量用户，那么您拥有的硬件可能不是问题。

<强>软件

如果您正在运行vmstat和iostat之类的内容，并且您没有找到任何特定的硬件瓶颈，则可能存在配置问题。确保配置了大量的Unicorn Worker，以便盒子可以正确使用您的硬件。

外部瓶颈

确保服务器上的网络速度等内容足以满足其需求。确保尝试访问服务器的用户不会因配置错误的网络而受到瓶颈。如果您正在使用OmniAuth，请确保提供程序正常运行。例如，如果您正在使用某些外部身份验证，并且不能正常扩展/执行，那么您在GitLab中的性能也会下降。如果您没有使用上述方法看到太多的硬件利用率，那么这些特别重要。

Answer 2

可以帮助加速GitLab的两个方面是最新的2020年4月12.10版本：

• 应用程序服务器which switches back Puma
• caching of Git info/refs

最后一点是：

从Git存储库获取更改时，服务器会发布存储库中所有分支和标签的列表，称为 refs 。

在某些情况下，我们观察到对GitLab Web服务器的所有请求中有多达75％是对引用的请求。
最好的情况是，当所有参考文件都打包好时，这是一种廉价的操作。

但是，当有解压缩的引用时，Git必须遍历解压缩的引用。这会导致额外的磁盘I / O，在使用诸如NFS之类的高延迟存储时，速度会很慢。

在GitLab 12.10中， info/refs 被缓存以提高引用广告的性能，并减少引用非常频繁获取的情况下对Gitaly的压力。

在GitLab.com上测试此功能时，我们发现读取操作的数量比写入操作的数量多10到1，并且中值延迟减少了70％。
对于使用NFS进行Git存储的GitLab实例，我们期望有更大的改进。

请参见Documentation和Issue。