SonarQube 分析需要太多时间答案

【问题标题】：SonarQube Analysis takes too much timeSonarQube 分析需要太多时间
【发布时间】：2015-01-29 00:23:15
【问题描述】：

尽管它似乎指向大量的代码行（500,000 行），但工程部门并不相信为什么在配备 16GB RAM 和双 CPU 的强大 Solaris 机器上需要 90 分钟才能完成一次声纳分析。请告诉我 90 分钟对于这种大小的代码库是否太多。

我正在使用 Jenkins git 插件从 Git 中检查代码，运行一个完整的 ant 构建，需要 45 分钟，然后运行“ant sonar”，它将数据填充到运行 4.1.2 并具有“质量配置文件”的 SonarQube 服务器作为由 findbugs、checkstyle 和 PMD 组成的默认配置文件。总时间为 45 + 90 分钟。

当我使用增量选项时，分析时间会减少，并且它确实“看到”了只需要分析一个文件。但是，根据文档，差异分析未填充到数据库中，因此使该选项对我的目的无用。

如何减少每次 SonarQube 分析所花费的时间？

【问题讨论】：

请不要在同一个问题中问很多不同的问题。我将删除您的第二个问题，因为它与您的问题的标题无关（“如果阻止者/违规的数量从构建到构建增加，我该如何“失败”构建？”）。
当然。对于那个很抱歉。 :)
有没有办法运行“增量”选项并且仍然将结果写入数据库？
不，增量分析目前只是一种“预览”模式。
90 分钟！！！！你如何做到这一点？我的项目有 1100 K LOC，分析耗时超过 12 小时（C# 项目）

标签： ant jenkins sonarqube analysis findbugs

【解决方案1】：

如果您的构建已经花费了 45 分钟，那么 SonarQube 分析也花费大量时间我并不感到惊讶。 500k LOC 对于单个项目来说已经很多了。

这里有一些减少时间的方法：

首先确保您在真实数据库上运行 SonarQube 服务器，而不是在 H2 上
然后，分析应该在非常靠近 SonarQube DB 的地方进行
- 如果可能在同一台机器上
- 如果不可能，分析和 DB 应位于同一个高带宽和高速 LAN 上
另外，请确保您只激活相关规则，而不是所有可用规则（有些甚至是多余的）

【讨论】：

是的，我们使用的是 mysql，而数据库确实在另一台机器上。但是，如果我没记错的话，写入数据库的实际时间并没有那么大，事实上，我需要回去检查一下，但即使我们在同一台机器上写入本地 h2 数据库，整个分析所花费的时间仍然大致相同。它必须是规则。谢谢！

【解决方案2】：

您基本上需要确定您的瓶颈。我们不知道您的（确切的）硬件、环境或配置 - 因此很难提供建议。

1.) 在我们的案例中（我们的项目有很多小文件），我们确定服务器 IO 是第一个限制因素 - 因此我们用 SSD 交换了我们的老式磁驱动器（在不同的设置中，SAS 磁盘也有很大帮助）并且声纳分析速度大大加快。

2.) 下一个限制是 CPU（GWT 浏览器排列编译），我们将 2 核 cpu 替换为 8 核 cpu...

3.) 作为第三件事，我们优化了我们的配置和设置（设置 localWorkers 等）。对于声纳，我们检查了所有 Findbugs、PMD 规则，这需要一些时间但值得。

因此，正如 Fabrice 建议的那样，您需要检查设置中的限制因素 - 网络可能是一回事...

现在您可能会问如何检测瓶颈 - 这取决于。例如我们这样检查的 IO：

在构建/声纳期间分析 CPU 负载历史记录（CPU 不忙）
我们创建了一个临时 RAM 驱动器（数 GB），并在其中运行构建和声纳分析，这证明 IO 是一个重要因素。此外，在该设置中，CPU 突然处于满负荷状态......

【讨论】：

识别瓶颈的一个例子。我们意识到“Sonar 的包设计分析部分在我们的构建中花费了非常长的时间（我相信这在一些大型代码库中是众所周知的）并且我们没有使用它的输出。我们禁用了“sonar.skipPackageDesign=true”和大大缩短了我们的分析时间。
AFAIK，SonarQube 分析是单线程的，因此增加内核数量应该不会产生太大影响，除非构建服务器正在运行许多相互减慢的并行构建。

【解决方案3】：

我发现的两个主要因素是您为测试的配置文件启用的规则数量和启用的插件类型。我可以想到两种方法来解决瓶颈的根本原因。

使用显着减少的规则数量运行分析，看看需要多长时间，然后如果您发现所用时间有很大差异，则逐渐增加规则。
禁用所有启用的插件，只保留必要的插件，看看是否节省时间，然后逐渐添加插件，一次一个，看看每个启用的插件增加了多少时间。

最后，我使用了 TeamCity，当我的分析持续到 3 个小时时，我查看了日志以查看哪些程序或插件需要时间，这有助于我缩小禁用哪个程序或插件的范围。按照这些步骤，我将分析时间从 3 小时缩短到 25 分钟。

【讨论】：