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

Question

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

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

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

---

分布：

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

场景：

• 调用配置文件页面（如nemo profiles page），缓存填充后报告第二次调用，平台上只有1个用户
• 在 logback.xml 的 INFO 中记录“rails”

虚拟机虚拟化：

• 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）：服务器和 H2 嵌入在同一 VM 上

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

个人测试：

• 2054ms（查看：542，DB：1506）：笔记本电脑 Dell Vostro 3300 上的服务器/NAS Qnap TS-219 上的 MySql
• 808ms（查看：528，DB：273）：Dell Vostro 3300 笔记本电脑上的服务器和 HsqlDB

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

为了乐趣和信息，SonarQube 在 Qnap TS-219 (CPU armv5tel !!) 上使用 Java Service Wrapper Linux CPU armel v3 工作（启动和配置文件咨询）。 5.22

• 13762ms (View: 10877, DB: 2832) : server & H2 Embedded on NAS Qnap TS-219
• 13622ms (View: 10581, DB: 2997) : server & MySQL on NAS Qnap TS-219

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

---

通过在 JMX 远程连接 JVisual 进行一些线程转储，75% 有这个堆栈（其他在 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 响应时间（以及更普遍的配置文件管理）可能有点奇怪。

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

Answer 1

讨论已切换到 SonarQube 用户邮件列表：http://sonar.markmail.org/thread/gbmj5dwyrrysujfo