Analysis takes longer time to start in sonarqube in 9.7.1

Hi ,

we were using Sonarqube 6.7.5 community edition in Datacenter and as part of cloud migration we deployed sonarqube (9.7.1 version - community edition ) in AWS

and we often face multiple issues in analysis,where

the analysis takes a longer time to get completed which was running for a few minutes in old sonarqube versions
or sometimes it takes a longer time to get started itself after submitting

enabled DEBUG mode and went through the CE logs but nothing major was found apart from the below ones.

sonar configuration that we use ,is there anything that we wanted to add to avoid these performance issues.

cat /apps/sonarqube_latest/conf/sonar.properties | grep -v ‘^#|^$’

sonar.jdbc.username=username
sonar.jdbc.password=secret
sonar.jdbc.url=sonarqube_endpoint
sonar.web.javaOpts=-Xmx3G -Xms3G -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts=-Xmx3G -Xms3G -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaOpts=-Xmx3G -Xms3G -XX:MaxDirectMemorySize=256m -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaAdditionalOpts=-Djava.security.policy=/apps/sonarqube_latest/elasticsearch/config/security.policy
http.proxyHost=outbound-proxy.services.aws.fico.com
http.proxyPort=3128
https.proxyHost=outbound-proxy.services.aws.fico.com
https.proxyPort=3128
sonar.log.level=INFO
sonar.path.data=/apps/sq-shared/data
sonar.path.temp=/apps/sq-shared/temp

CE logs:

tail -f ce.log


2023.07.20 10:41:43 DEBUG ce[][o.i.c.TaskRunner] Q10000 finished run in 107 µs: OkHttp ConnectionPool

2023.07.20 10:41:53 DEBUG ce[AYly2SAb4ynx_oPxoYAK][o.s.s.w.WebHooksImpl] Failed to send webhook 'pblue-webhook' | url=https://pblue-dev-jenkins.aws.fico.com/sonarqube-webhook/ | message=Socket closed

2023.07.20 10:41:53 INFO ce[AYly2SAb4ynx_oPxoYAK][o.s.c.t.p.a.p.PostProjectAnalysisTasksExecutor] Webhooks | globalWebhooks=2 | projectWebhooks=0 | status=SUCCESS | time=10132ms

2023.07.20 10:41:53 DEBUG ce[AYly2SAb4ynx_oPxoYAK][o.s.c.a.AnnotationConfigApplicationContext] Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@696167f6, started on Thu Jul 20 10:38:02 UTC 2023, parent: org.springframework.context.annotation.AnnotationConfigApplicationContext@7e483d02

2023.07.20 10:41:53 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - Before cleanup stats (total=10, active=0, idle=10, waiting=0)

2023.07.20 10:41:53 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - After cleanup stats (total=10, active=0, idle=10, waiting=0)

2023.07.20 10:41:53 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - Fill pool skipped, pool has sufficient level or currently being filled (queueDepth=0).

2023.07.20 10:42:23 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - Before cleanup stats (total=10, active=0, idle=10, waiting=0)

2023.07.20 10:42:23 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - After cleanup stats (total=10, active=0, idle=10, waiting=0)

2023.07.20 10:42:23 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - Fill pool skipped, pool has sufficient level or currently being filled (queueDepth=0).

2023.07.20 10:58:53 DEBUG ce[][c.z.h.p.HikariPool] HikariPool-1 - Fill pool skipped, pool has sufficient level or currently being filled (queueDepth=0).

2023.07.20 10:58:53 DEBUG ce[][c.z.h.pool.PoolBase] HikariPool-1 - Closing connection org.postgresql.jdbc.PgConnection@4dd5222a: (connection has passed idleTimeout)

ar.ce.task.projectanalysis.step.ExecuteVisitorsStep' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.qualitymodel.SecurityReviewMeasuresVisitor'

2023.07.20 11:24:06 DEBUG ce[AYly35AU4ynx_oPxoYAb][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.step.ExecuteVisitorsStep' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.qualitymodel.NewSecurityReviewMeasuresVisitor'

2023.07.20 11:24:06 DEBUG ce[AYly35AU4ynx_oPxoYAb][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.step.ExecuteVisitorsStep' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.source.LastCommitVisitor'

2023.07.20 11:24:06 DEBUG ce[AYly35AU4ynx_oPxoYAb][o.s.c.p.PriorityBeanFactory] Autowiring by type from bean name 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.step.ExecuteVisitorsStep' via constructor to bean named 'jdk.internal.loader.ClassLoaders$AppClassLoader@8bcc55f-org.sonar.ce.task.projectanalysis.measure.MeasureComputersVisitor'

below community link , below talks about purging old data and not sure how much it would be helpful .

do refer screenshots for more info regarding the analysis time


Hi,

It’s not clear to me why you would choose 9.7.1 to jump to. It’s EOL, although not as severely outdated at 6.7.5.

You should adopt the current LTS, 9.9.1, or the latest version, 10.1.

And be aware that A LOT has changed since 6.7.5: new analyzers, new rules, and much, much smarter rules.

Once you get to a current version, if you still feel your analyses are taking too long versus the value they deliver, then we can discuss it.

 
Ann

Hi Ann,

I will check on this and see if the latest version helps in faster analysing

and I hope the recent version doesn’t have any significant configuration changes, will go through the change logs and proceed

Hii Ann,

We tried 9.9.1 LTS version and found analysis was good when using embedded DB but when we tried to use aurora PostgreSQL DB of 13.6 version

and refer the configurations used below .

sonar.jdbc.username=username
sonar.jdbc.password=secret
sonar.jdbc.url=sonarqube_endpoint
sonar.web.javaOpts=-Xmx3G -Xms3G -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts=-Xmx3G -Xms3G -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaOpts=-Xmx3G -Xms3G -XX:MaxDirectMemorySize=256m -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaAdditionalOpts=-Djava.security.policy=/apps/sonarqube_latest/elasticsearch/config/security.policy
http.proxyHost=outbound-proxy.services.aws.fico.com
http.proxyPort=3128
https.proxyHost=outbound-proxy.services.aws.fico.com
https.proxyPort=3128
sonar.log.level=INFO
sonar.path.data=/apps/sq-shared/data
sonar.path.temp=/apps/sq-shared/temp

do let us know how can we fix this performance issues when we use external DB with sonarqube

Hi,

I think something got left out here:

“but when we tried to use auroroa PostgreSQL DB…” what? What happened when you tried to use Postgres?

 
Ann

sorry , didn’t complete my sentence in previous chat ,

when using embedded database, analysis looks good as shown below

Sonarqube 9.9.1 LTS with embedded DB

analysis of huge projects takes less than 2 mins

Sonarqube 9.9.1 LTS with RDS aurora postgresql

but the same project when analysed after configuring RDS aurora postgresql (13.6 version ) ,performance is degraded and it takes more than 20 mins for analysis

we are trying to figure out why the performance is not good with RDS and better with embedded Database,do let us know if we want to configure anything else
RDS instance type used : db.r5.4xlarge which has 16 128 CPU and 128 GB memory ,also we didnt face any major isses from cloudwatch metrics .
if there are anything suggested for this scenario, we can try that.

Hi,

Do your DBAs have an opinion on this?

Also, is SonarQube close to the DB on your network? That may be the root of this, since the embedded DB is… embedded in SonarQube - i.e. it’s on the same host with nearly 0 transit time for requests.

 
HTH,
Ann

we are checking with them ,meanwhile we want suggestions from sonarqube end as well,

do you think if we change the DB engine to MySQL etc, will there be a better results

Hi,

I have nothing to lead me to believe that switching DBs will speed this up.

I’ll be interested to hear what your DBAs say.

 
Ann

Hi Ann,

We found the delay in the analysis was due to the extraction of an analysis report , after we modified the sonar.path.temp from our EFS volume to EBS, total analysis time was reduced from 22 mins to 3 mins, thanks for your assistance.

3 Likes

Hi,

Thanks for sharing your solution! I’ve made a note to see if we want to add something about this to the docs.

 
Thx,
Ann