我们的 GitLab 经常变慢 | 那些遇到过的问题

这些只是一些不提供保修的原样建议，但它们可能有助于指导您解决问题。

奥卡姆剃刀

您提到这些问题似乎是最近才开始出现的。这意味着首先要查看的是这些问题发生期间可能发生的变化。如果您对基础架构有变更控制，请从这里开始。绝对确保在这些问题开始发生时没有人做出任何改变。检查日志中是否有任何可能已开始出现的警告。如果您的操作系统有安全日志或日志配置更改，请检查它们。如果您对环境没有良好的可见性/审核能力，这可能会很困难，但如果您可以识别出在这些问题开始发生的同时发生变化的内容，那么这通常就是您的问题。

特异性

描述速度变慢的含义可能会对您有所帮助。是否是某个特定操作速度慢？还是这一切都是活动？如果是特定的事情，比如触发 Jenkins 作业，那么您可以开始在那里隔离您的搜索。

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

硬件

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

我建议vmstat在服务器上运行（因为它是 GitLab，我假设它在 Linux 上运行，因为他们不推荐 Windows 安装）以获得有关正在发生的情况的一些基本信息。该vmstat命令将为您提供几列信息。最左边应该有一列“r”。这是“运行队列”，或等待在 CPU 上运行的进程数。如果该列中的值与系统的核心数量相比较大，则可能存在 CPU 瓶颈。下一列“b”是被阻止的进程。如果这个值很大，则可能没有 CPU 瓶颈。右侧有 CPU 列：us、sy、id 或类似的内容。这些列详细说明了 CPU 的时间消耗在应用程序代码 (us)、操作系统代码 (sy) 或等待 (id) 中。我们的高百分比数字通常表明您运行正常或存在 CPU 瓶颈。sy 中的高百分比数字通常表示某种争用，可能是配置问题，例如为您拥有的 CPU 数量配置了太多工作线程。id 中的百分比数字较高通常表明系统要么没有执行太多操作，要么无法执行太多操作，因为它正在等待磁盘或外部数据库等内容。

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

需要注意的一件事是，如果您发现 CPU 瓶颈（高 r 值、高 us 值），请确保这种情况对于您拥有的用户数量来说是有意义的。CPU瓶颈可能是由虚拟化问题或某些操作系统问题导致CPU性能不佳引起的，而不仅仅是CPU硬件本身不足造成的。

拓扑结构

我在上面链接的 gitlab 要求中提到的一件事是，不建议在与 GitLab 本身相同的机器上运行 GitLab 运行程序。我想说，对于任何与 GitLab 一起使用的 CI 软件来说都是如此。如果您在与 GitLab 本身相同的机器上运行 GitLab Runner 或 Jenkins，您应该考虑将它们移动到自己的硬件上。

如果您有数千名用户，您可能希望与 GitLab 本身联系，并就如何建立企业级集群及其外观进行咨询。有些人是对大型 GitLab 安装有意义的特定硬件配置方面的专家，但我不是其中之一。但是，如果您没有大量用户，那么您拥有的硬件可能不是问题。

软件

如果您正在运行诸如vmstat和之类的东西iostat，并且没有发现任何特定的硬件瓶颈，则可能存在配置问题。确保您配置了足够数量的 Unicorn Workers，以便盒子可以正确利用您的硬件。

外部瓶颈

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