Sonarqube Web UI配置文件管理在Oracle中很慢 [英] Sonarqube web UI profiles management is slow with Oracle
问题描述
在虚拟化环境(生产环境)中将SonarQube与Oracle一起安装时，与其他具有相同分发版本的安装相比，配置文件管理非常慢.
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)
在VM环境上进行的测试:
- 8093ms(查看:7219，DB:864):VM上的服务器/VM上的Oracle
- 2206ms(查看:1851，数据库:346):服务器& 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.
个人测验:
- 2054ms(查看:542，DB:1506):笔记本电脑Dell Vostro 3300上的服务器/NAS Qnap TS-219上的MySql
- 808ms(查看:528，数据库:273):服务器&笔记本电脑Dell Vostro 3300上的HsqlDB
=>远程数据库对View部分没有影响(在这种情况下为MySQL)
=> Distant Database has no impact on View part (with MySQL in this case)
为了娱乐&信息，SonarQube(使用Java服务包装器 Linux CPU框架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(查看:10877，数据库:2832):服务器&嵌入在NAS Qnap TS-219上的H2
- 13622ms(查看:10581，DB:2997):服务器& 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方言可以解释许多配置文件时的这些响应时间)
- Many time to generate java exception (CPU cost not negligible) ? (or programming by exception is a desired process)
- Especially with Oracle connector ? (Or the Oracle dialect used to generate request could explain these responses time when many profiles)
也许我在没有问题的地方遇到了问题，但是在此页面上对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.
推荐答案
The discussion has switched to the SonarQube user mailing list : http://sonar.markmail.org/thread/gbmj5dwyrrysujfo
这篇关于Sonarqube Web UI配置文件管理在Oracle中很慢的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
