Installing SonarQube with Oracle on a virtualized environment (production), the profiles management is very slow compared to other installation with same distribution.
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.
Distribution :
- SonarQube 3.7.3 with 39 plugins (jar files in extensions/plugins/)
- 9 languages profiles : C#/C++/Flex/Java/JavaScript/PHP/Python/Web/XML (Problem increases with number of profiles)
- clean installation (no projects analysed, profiles by default)
Scenario :
- 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
VM virtualized :
- Linux SLES 11 (patch 2) x86 64b
- DELL R815 / 16 core AMD (guaranteed for SonarQube VM : 1 core & 8 Go)
Tests on VM environment :
- 8093ms (View: 7219, DB: 864) : server on VM / Oracle on VM
- 2206ms (View: 1851, DB: 346) : server & H2 Embedded on same VM
=> 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.
Personal tests :
- 2054ms (View: 542, DB: 1506) : server on Laptop Dell Vostro 3300 / MySql on NAS Qnap TS-219
- 808ms (View: 528, DB: 273) : server & HsqlDB on Laptop Dell Vostro 3300
=> Distant Database has no impact on View part (with MySQL in this case)
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 Embedded on NAS Qnap TS-219
- 13622ms (View: 10581, DB: 2997) : server & MySQL on NAS Qnap TS-219
=> Qnap TS-219 is not enough for SonarQube (CPU saturation ;-)).
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)
Hypothesis :
- 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)
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.
