0

我最近将我们的 SonarQube 实例升级到了 5.1.2。我们使用 SVN 插件 (v1.1) 进行 SCM 分析。自升级以来，该插件的性能一直非常缓慢。

为了重现该问题，我在我自己的 PC 上针对 2 个 SonarQube 安装（也安装在我的 PC 上 - 4.4.1 和 5.1.2）分析了一个项目。

4.4.1 的 SCM 分析耗时 45 秒，而 5.1.2 版本耗时近 1.5 小时。

以下是来自日志文件的示例片段。4.4.1版本没有说明分析的文件个数，但是和5.1.2分析的一样（同一个项目）。

4.4.1 版：

[INFO] [17:53:21.914] Sensor ScmActivitySensor...
[INFO] [17:53:21.914] Trying to guess scm provider from project layout...
[INFO] [17:53:21.915] Found SCM type: svn
[INFO] [17:53:21.915] Retrieve SCM blame information with encoding windows-1252...
...
[INFO] [17:54:06.488] Retrieve SCM blame information with encoding windows-1252 done: 44573 ms
[INFO] [17:54:06.488] Sensor ScmActivitySensor done: 44574 ms

版本 5.1.2：

[INFO] [18:00:54.971] Sensor SCM Sensor
[INFO] [18:00:54.987] SCM provider for this project is: svn
[INFO] [18:00:54.991] 1645 files to be analyzed
...
[INFO] [19:27:16.017] 1645/1645 files analyzed
[INFO] [19:27:16.017] Sensor SCM Sensor (done) | time=5181046ms

这似乎排除了我们的 SVN 服务器或执行分析的机器的问题。我不知道下一步该往哪里看？任何人都可以帮忙吗？

如果需要，我可以提供完整的日志（尽管 5.1.2 中的调试输出似乎没有显示任何有用的额外内容）。

4

1 回答 1

0

正如我在评论中提到的，这是因为合并历史包含在 SVN 的责备中。

如果您坚持下去并等待一个分析完成，那么后续分析会快得多，因为责备操作仅对更改的文件执行。

于 2015-09-01T14:26:20.697 回答