在 SonarQube 仪表板中，分配问题需要很长时间

Question

注意：最初发布在 SonarQube 用户邮件列表上，该列表现已关闭，因此将其移至此处。

我安装了 SonarQube 5.0.1。即使没有运行分析作业，用户也需要很长时间才能从 Web 仪表板编辑问题（例如分配问题）。我将服务器日志记录打开为“FULL”，并注意到在将记录插入 issue_changes 和以下选择问题查询之间，主要时间正在消耗，如下所示。它似乎正在等待和轮询一些通知。

这里是日志条目：

2015.05.28 14:18:02 INFO  http-bio-0.0.0.0-9000-exec-2 web[sql]  15ms Executed SQL: update issues set action_plan_key=?, severity=?, manual_severity=?, ...
2015.05.28 14:18:02 INFO  http-bio-0.0.0.0-9000-exec-2 web[sql]  0ms Executed SQL: INSERT INTO issue_changes (kee, issue_key, user_login, change_type, change_data, ...
2015.05.28 14:18:38 INFO  pool-5-thread-1 web[sql]  0ms Executed SQL: select id, data from notifications order by id asc limit ? - parameters are: <1>
2015.05.28 14:19:38 INFO  pool-5-thread-1 web[sql]  0ms Executed SQL: select id, data from notifications order by id asc limit ? - parameters are: <1>
2015.05.28 14:20:38 INFO  pool-5-thread-1 web[sql]  0ms Executed SQL: select id, data from notifications order by id asc limit ? - parameters are: <1>
2015.05.28 14:20:53 INFO  pool-2-thread-3 web[sql]  171370ms Executed SQL: select i.kee,root.uuid,i.updated_at,i.action_plan_key,i.assignee,i.effort_to_fix,i.issue_attributes,...
2015.05.28 14:20:53 INFO  pool-2-thread-3 web[bulk]  15ms ES bulk request for [Action 'UpdateRequest' for key '9b985185-349f-48a8-9762-21ec952c66ea' on index 'issues' on type 'issue'],
2015.05.28 14:20:53 INFO  pool-2-thread-3 web[refresh]  63ms ES refresh request on indices 'issues'
2015.05.28 14:20:53 INFO  http-bio-0.0.0.0-9000-exec-2 web[get]  0ms ES get request for key 'intellijinspection:ConstantConditions' on index 'rules' on type 'rule'

附加卷信息：我有大约 17 个项目，每个项目有 22 个模块，每个项目总共有 300 万行代码和 20 万个问题。

更新：

所以在对代码进行了一些挖掘之后，我了解到当用户编辑保存时会调用以下内容，这会导致索引就地完成。因此，在上面的选择查询中报告的迭代和索引在其结果集上发生所消耗的时间。

ServerIssueStorage {

    ....

    @Override
    protected void doAfterSave() {
        indexer.index();
    }

}

我猜这是 SQ 团队警告升级到 5.* 版本的原因之一，如果你有并且问题计数 > 5M。

知道版本何时开始支持此卷吗？在此之前是否有任何解决方法可以以其他方式缓解此问题？

Answer 1

确实，在 5.0 版中，整体性能可能会受到并行分析数量的影响（例如，在多个 jenkins 从站上安排的持续检查）。这个限制在 5.1 中得到了改进，并且在 5.2 中继续努力。