Oracle 的 Sonarqube Web UI 配置文件管理速度很慢

本文介绍了Oracle 的 Sonarqube Web UI 配置文件管理速度很慢的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

在虚拟化环境(生产)上使用 Oracle 安装 SonarQube，与具有相同发行版的其他安装相比，配置文件管理非常慢.

Installing SonarQube with Oracle on a virtualized environment (production), the profiles management is very slow compared to other installation with same distribution.

当在此架构(虚拟化 Linux + Oracle)上使用许多配置文件时，我将感谢有关此功能响应时间的一些反馈.

I will be grateful of some feedbacks about response time of this functionality when many profiles used on this architecture (Virtualized Linux + Oracle).

下面的测试和快速分析以提供一些信息/案例再现.

Tests below and a quick analysis to give some informations / case reproduction.

分布:

具有 39 个插件的 SonarQube 3.7.3(扩展/插件/中的 jar 文件)
9 种语言配置文件:C#/C++/Flex/Java/JavaScript/PHP/Python/Web/XML(问题随着配置文件数量的增加而增加)
全新安装(不分析项目，默认配置文件)

场景:

调用个人资料页面(如 nemo 个人资料页面)，报告第二次通话缓存填满后，平台上只有 1 个用户
在 logback.xml 的 INFO 中记录rails"

Calling profiles page (as nemo profiles page), second call reported after cache filled, only 1 user on platform
Log 'rails' in INFO in logback.xml

虚拟机虚拟化:

Linux SLES 11(补丁 2)x86 64b
DELL R815/16 核 AMD(SonarQube VM 保证:1 核和 8 Go)

虚拟机环境测试:

8093ms(查看:7219，DB:864):VM 上的服务器/VM 上的 Oracle
2206ms (查看: 1851, DB: 346) : server &H2 嵌入在同一虚拟机上

=> H2 的响应时间可以接受(VM 上的 CPU 频率不是很高)，因此没有 CPU/IO/RAM 饱和.但 Oracle 对 View 部分有些怀疑.

=> Response time acceptable with H2 (CPU frequency not very high on VM), so no CPU/IO/RAM saturation. But some suspicions with Oracle about View part.

个人测试:

2054 毫秒(查看:542，DB:1506):笔记本电脑 Dell Vostro 3300 上的服务器/NAS Qnap TS-219 上的 MySql
808ms (View: 528, DB: 273) : server &戴尔 Vostro 3300 笔记本电脑上的 HsqlDB

=> 远程数据库对视图部分没有影响(本例中使用 MySQL)

=> Distant Database has no impact on View part (with MySQL in this case)

为了好玩和信息，SonarQube 使用 Java Service Wrapper Linux CPU armel v3.5.22

For fun & info, SonarQube works (starting and profiles consultation) on Qnap TS-219 (CPU armv5tel !!) with Java Service Wrapper Linux CPU armel v3.5.22

13762ms (View: 10877, DB: 2832) : server &H2 嵌入 NAS Qnap TS-219
13622ms (查看: 10581, DB: 2997) : server &NAS Qnap TS-219 上的 MySQL

=> Qnap TS-219 对于 SonarQube 来说是不够的(CPU 饱和 ;-)).

=> Qnap TS-219 is not enough for SonarQube (CPU saturation ;-)).

通过在 JMX 远程连接 JVisual 以进行一些线程转储，75% 有这个堆栈(其他在 RuntimeCache.getConstantFrom 之前是等效的):

With connecting JVisual in JMX remote for taking some thread dump, 75% have this stack (other are equivalent until RuntimeCache.getConstantFrom) :

 java.lang.Thread.State: RUNNABLE
    at java.lang.Throwable.getStackTraceElement(Native Method)
    at java.lang.Throwable.getOurStackTrace(Throwable.java:591)
    - locked <5512520e> (a java.lang.Exception)
    at java.lang.Throwable.getStackTrace(Throwable.java:582)
    at java.lang.Thread.getStackTrace(Thread.java:1479)
    [...]
    at org.jruby.RubyException.prepareBacktrace(RubyException.java:160)
    [...]
    at org.jruby.exceptions.RaiseException.<init>(RaiseException.java:141)
    [...]
    at org.jruby.Ruby.newNameError(Ruby.java:3243)
    at org.jruby.RubyModule.const_missing(RubyModule.java:2647)
    at org.jruby.RubyModule$i$1$0$const_missing.call(RubyModule$i$1$0$const_missing.gen:65535)
    [...]
    at rubyjit.ActiveSupport::Dependencies::ClassConstMissing#const_missing_1F94EEFD25B9D6ED4A2256A01713AC5D8AAE19F9.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activesupport-2.3.15/lib/active_support/dependencies.rb:118)
    at rubyjit.ActiveSupport::Dependencies::ClassConstMissing#const_missing_1F94EEFD25B9D6ED4A2256A01713AC5D8AAE19F9.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activesupport-2.3.15/lib/active_support/dependencies.rb)
    [...]
    at org.jruby.RubyModule.fastGetConstantFromConstMissing(RubyModule.java:2974)
    at org.jruby.ast.executable.RuntimeCache.getConstantFrom(RuntimeCache.java:418)
    at org.jruby.ast.executable.AbstractScript.getConstantFrom0(AbstractScript.java:292)
    at rubyjit.ArJdbc::Oracle#sql_literal?_35B81FE146BCEA62ED756B5BE2D767870ADF57AC.rescue_1$RUBY$SYNTHETIC__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/oracle/adapter.rb)
    at rubyjit.ArJdbc::Oracle#sql_literal?_35B81FE146BCEA62ED756B5BE2D767870ADF57AC.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/oracle/adapter.rb:162)
    at rubyjit.ArJdbc::Oracle#sql_literal?_35B81FE146BCEA62ED756B5BE2D767870ADF57AC.__file__(/[sonar-dir]/sonar-3.7.3/war/sonar-server/WEB-INF/gems/gems/activerecord-jdbc-adapter-1.1.3/lib/arjdbc/oracle/adapter.rb)
    [.......]
    at org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:74)
    [...]
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
    at java.lang.Thread.run(Thread.java:662)

假设:

多次产生java异常(CPU开销不可忽略)?(或异常编程是一个理想的过程)
尤其是使用 Oracle 连接器?(或者在许多配置文件时，用于生成请求的 Oracle 方言可以解释这些响应时间)

也许我看到了没有的问题......但是这个页面上的 Oracle 响应时间(以及更普遍的配置文件管理)可能有点奇怪.

Perhaps I see problems where there are not ... but this response time with Oracle on this page (and more generally on profiles management) could be a little strange.

提前感谢您的反馈或想法.

Thanks in advance for feedbacks or ideas.

thread

Oracle 的 Sonarqube Web UI 配置文件管理速度很慢

问题描述

推荐答案