SonarQube 后台任务运行超过 4 小时答案

【问题标题】：SonarQube background tasks runs past 4 hourSonarQube 后台任务运行超过 4 小时
【发布时间】：2018-07-27 12:28:26
【问题描述】：

我们正在将我们的 SonarQube 从 4.5.X 升级到 5.6.X，计算引擎是一个新概念，并且在纸面上非常闪亮。 ~~但是当投入工作时，它的表现并不好！如果你成功了，请帮助我度过难关~~

我选择了一个使用 SonarQube 4.5.4 在 4 分钟内完成扫描的测试项目。现在使用（gradle）扫描仪进行的初始扫描需要 3 分钟。并且 CE 后台任务永远运行，在测试项目之外，第一个在 183 分钟内完成，另一个在 263 分钟内完成，第三个仍在运行。

显然，我挖掘并看到了这个 stackoverflow 问题 - Sonarqube background tasks running forever 并增加了作为答案引用的内存，但它对我不起作用。

sonar.ce.javaOpts=-Xmx4096m -Xms512m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true
sonar.ce.workerCount=5

虽然工人数是 5，但我现在没有运行并行任务。从已完成作业的日志中，我可以看到一些令人震惊的时间信息！

2018.02.13 16:56:07 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute complexity measures | time=335ms
2018.02.13 16:56:07 INFO  [o.s.s.c.s.ComputationStepExecutor] Load measure computers | time=6ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   Execution time for each component visitor:
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LoadComponentUuidsHavingOpenIssuesVisitor | time=2483ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - IntegrateIssuesVisitor | time=15743879ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - CloseIssuesOnRemovedComponentsVisitor | time=0ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - QualityModelMeasuresVisitor | time=143ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - NewQualityModelMeasuresVisitor | time=73ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LastCommitVisitor | time=4ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - MeasureComputersVisitor | time=25ms
2018.02.13 21:18:34 INFO  [o.s.s.c.s.ComputationStepExecutor] Execute component visitors | time=15746700ms
2018.02.13 21:18:37 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute measure variations | time=3290ms
2018.02.13 21:18:37 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute Quality Gate measures | time=54ms
2018.02.13 21:18:37 INFO  [o.s.s.c.s.ComputationStepExecutor] Compute Quality profile measures | time=25ms
2018.02.13 21:18:38 INFO  [o.s.s.c.s.ComputationStepExecutor] Generate Quality profile events | time=33ms
2018.02.13 21:18:38 INFO  [o.s.s.c.s.ComputationStepExecutor] Generate Quality gate events | time=6ms

执行组件访问者，尤其是IntegrateIssuesVisitor 需要大量时间，执行所需的总时间为 263 分钟，其中 262 分钟。 如何避免这种情况？

我没有看到任何跨项目分析禁用选项，是否与此有关？

其他信息： 我使用 Oracle 数据库

[更新] 删除 CE 上的诅咒。我的错，CE很棒！现在部分项目3秒分析发布！！

【问题讨论】：

首先，对于您的基础架构而言，5 个工作人员可能太多了。请参阅guidance in the docs。其次，6.7.1 是当前的 LTS。如果你正在迁移，你应该一路跳跃；两个版本之间有许多增强和改进（包括性能增强！）
感谢 cmets @G.Ann-SonarSourceTeam 但工人数量就在那里，我什至没有使用 2 个线程。我还分配了 4gb 的堆空间。 CPU 99% 空闲，11gb 15gb 可用 RAM 空闲！将此视为婴儿步骤，我们正在计划 6.7.1，但只有在成功迁移到 5.6.7
如果能深入了解IntegrateIssuesVisitor | time=15743879ms就太好了
使用相同的 java 选项，将 worker 数量减少到 1；仍然时间运行还没有下来！我只是让长时间运行的扫描在周末完成，花了 13 个小时！！！
听起来托管您的 SonarQube 服务器的机器功率不足。 Compute Engine 的引入将繁重的工作从分析框转移到了 SQ 框。

标签： sonarqube sonarqube-ops sonarqube5.6

【解决方案1】：

解决了！

正如 SonarQube Google 小组的讨论所指出的那样，它与数据库有关。

来自https://docs.sonarqube.org/display/PLUG/Managing+Compute+Engine+Performance，很明显，Compute Engine 的性能与，

数据库
磁盘 I/O
网络
堆
CPU

我们的内存消耗和 CPU 使用率总是最低的，所以我们立即排除了最后两个。但是我们还不知道出了什么问题，如果任何 CE 日志在各个方面都是无用的，因为日志级别没有应用于 CE 日志，那么您就是只有 INFO 没有 DEBUG 或 TRACE 级别的东西。我们还是得到了提示，

INFO  [o.s.s.c.s.ExecuteVisitorsStep]   Execution time for each component visitor:
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LoadComponentUuidsHavingOpenIssuesVisitor | time=58ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - IntegrateIssuesVisitor | time=41147606ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - CloseIssuesOnRemovedComponentsVisitor | time=1ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - QualityModelMeasuresVisitor | time=206ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - NewQualityModelMeasuresVisitor | time=119ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - LastCommitVisitor | time=6ms
INFO  [o.s.s.c.s.ExecuteVisitorsStep]   - MeasureComputersVisitor | time=29336ms

IntegrateIssuesVisitor 的执行时间非常长，日志信息量仅此而已，原因仍然是个谜。所以我们决定挖掘代码，感谢上帝，SonarQube 是开源的，但很快，或者 DBA 团队打电话给我们，为什么我们的查询表现如此糟糕。它卡住了我们，索引我们分析了 Sonar 的事务表，我们现在很好。

tl;dr ：保持更新表统计信息，以便优化始终对您有利。分析表格。

【讨论】：