注意:这是最初在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个模块,总共3M行代码和每个200K问题。
更新:
因此,在对代码进行一些挖掘之后,我了解当用户编辑保存时会调用以下内容,这会导致索引就地完成。因此,上面的选择查询报告的消耗时间是迭代和索引在其结果集上发生的。
ServerIssueStorage {
....
@Override
protected void doAfterSave() {
indexer.index();
}
}
我想这就是为什么SQ团队提醒升级到5. *版本的原因之一,如果你有和发行计数&gt; 5M。
知道什么时候发布会开始支持这个卷?是否有任何可行的解决方法可以在此之前解决此问题?
答案 0 :(得分:1)
事实上,在5.0版中,整体性能可能会受到并行分析数量的影响(例如,在多个詹金斯奴隶上安排的连续检查)。这种限制在5.1中得到了改善,并且在5.2中继续努力。