Details:
SonarQube 9.9.1 LTS Developer edition
GitHub PR scan: uses: sonarsource/sonarqube-scan-action@master
SonarScanner 4.8.0.2856
Java 11.0.19 Alpine (64-bit)
Linux 5.15.0-70-generic amd64
Analyzing on SonarQube server 9.9.1.69595
We previously trailed Enterprise edition. PR scan was fast after we disabled custom plugins.
We decided to go with the Developer edition, with the plugins still disabled.
From the logs I could trace it to Sensor javabugs [dbd] being slow.
Reading this topic: Analysis performance decreased due to “javabugs” Sensor - SonarCloud - Sonar Community (sonarsource.com)
I set sonar.internal.analysis.dbd=false in our sonar-project.properties file, which seems to work.
Checking the rules related to this repo: https://XXXXX:9000/coding_rules?repositories=javabugs&selected=javabugs%3AS6416
We only have this rule active on our custom quality profile: javabugs:S6320
Metrics for PR scan:
Sensor javabugs [dbd] (done) | time=1395964ms
Analyzing 191719 functions to detect bugs.
repo has about 3 million LoC
My question:
What can I do to make PR analysis fast again without having to disable javabugs [dbd]?
Other timings:
2023-07-01T15:43:03.7543575Z INFO: Sensor JavaSensor [java] (done) | time=104243ms
2023-07-01T15:43:03.7740301Z INFO: Sensor IaC CloudFormation Sensor [iac] (done) | time=19ms
2023-07-01T15:43:03.7827093Z INFO: Sensor IaC Kubernetes Sensor [iac] (done) | time=9ms
2023-07-01T15:43:03.7873666Z INFO: Sensor C# Project Type Information [csharp] (done) | time=4ms
2023-07-01T15:43:03.7983021Z INFO: Sensor C# Analysis Log [csharp] (done) | time=10ms
2023-07-01T15:43:03.7987700Z INFO: Sensor C# Properties [csharp] (done) | time=0ms
2023-07-01T15:43:03.7997702Z INFO: Sensor SurefireSensor [java] (done) | time=1ms
2023-07-01T15:43:03.8373658Z INFO: Sensor HTML [web] (done) | time=37ms
2023-07-01T15:43:03.8792809Z INFO: Sensor XML Sensor [xml] (done) | time=41ms
2023-07-01T15:43:04.1908282Z INFO: Sensor TextAndSecretsSensor [text] (done) | time=311ms
2023-07-01T15:43:04.1983238Z INFO: Sensor VB.NET Project Type Information [vbnet] (done) | time=8ms
2023-07-01T15:43:04.2096414Z INFO: Sensor VB.NET Analysis Log [vbnet] (done) | time=11ms
2023-07-01T15:43:04.2102474Z INFO: Sensor VB.NET Properties [vbnet] (done) | time=0ms
2023-07-01T15:43:04.2125884Z INFO: Sensor JaCoCo XML Report Importer [jacoco] (done) | time=2ms
2023-07-01T15:43:04.2222363Z INFO: Sensor JavaScript inside YAML analysis [javascript] (done) | time=9ms
2023-07-01T15:43:04.2516633Z INFO: Sensor CSS Rules [javascript] (done) | time=29ms
2023-07-01T15:43:04.2526124Z INFO: Sensor ThymeLeaf template sensor [securityjavafrontend] (done) | time=1ms
2023-07-01T15:43:04.4953349Z INFO: Sensor IaC Docker Sensor [iac] (done) | time=242ms
2023-07-01T15:43:04.5099399Z INFO: Sensor Serverless configuration file sensor [security] (done) | time=14ms
2023-07-01T15:43:04.5228032Z INFO: Sensor AWS SAM template file sensor [security] (done) | time=13ms
2023-07-01T15:43:04.5346829Z INFO: Sensor AWS SAM Inline template file sensor [security] (done) | time=12ms
2023-07-01T15:43:04.5353146Z INFO: Sensor javabugs [dbd] (done) | time=0ms
2023-07-01T15:43:04.5355140Z INFO: Sensor pythonbugs [dbd] (done) | time=0ms
2023-07-01T15:43:04.5367261Z INFO: Sensor JavaSecuritySensor [security] (done) | time=1ms
2023-07-01T15:43:04.5390412Z INFO: Sensor CSharpSecuritySensor [security] (done) | time=2ms
2023-07-01T15:43:04.5397648Z INFO: Sensor PhpSecuritySensor [security] (done) | time=1ms
2023-07-01T15:43:04.5404792Z INFO: Sensor PythonSecuritySensor [security] (done) | time=1ms
2023-07-01T15:43:04.5412803Z INFO: Sensor JsSecuritySensor [security] (done) | time=1ms
2023-07-01T15:43:04.6045671Z INFO: Sensor Analysis Warnings import [csharp] (done) | time=1ms
2023-07-01T15:43:04.6087284Z INFO: Sensor Dependency-Check [dependencycheck] (done) | time=3ms
To answer my own question. There seems to be a fix:
[URGENT] Analyzing functions never stops - SonarCloud - Sonar Community (sonarsource.com)
Will this fix be available in 9.9.2?
Hello @Dennis_DECA, thank you for your report.
The fix mentioned in the other thread has already been released more than a year ago, so it’s already part of the version you are using.
Given the size of the codebase, this running time is not entirely unreasonable for a project of this size. However, in order to see if we have some performance bottlenecks which we could improve on, could you send me the contents of the ir/java directory in a private message so that we can investigate further? The full path of this directory should be visible from the logs:
Reading IR files from: /tmp/build/project/target/sonar/ir/java
1 Like
Below the feedback I got, I thought was interesting to share.
Hey Dennis,
Thanks a lot for the IR files. I tried to reproduce the running times locally, however, on my machine the javabugs sensor finishes in 4 minutes. The only way I can reproduce the long running time is by setting a lower memory limit for the JVM (<4G), so a lot of CPU time is spent on garbage collection. Could you check if the situation improves by allowing more memory for the machine and the JVM (you can see how to increase memory for SonarScanner here and here)?
Regarding analyzing only the diffs: many of our rules are able to leverage diff information to only analyze the changed parts of the code. Unfortunately, the rules executed as part of the javabugs sensor do not support PR analysis yet, so they have to perform a full analysis every time they are executed. This is something we plan to look into.
Let me know if this helps.
Cheers,
Gyula
Thank you for your investigation. Interesting information. I hope in the future you manage to optimize the javabugs for PR diffs.
We are using self-hosted GitHub runners and the machines have 32GB of memory each.
I tried updating the workflow, but it seemed to make little difference. Even the normal java sensor rules takes 20+ minutes. Only once every so often it seems to finish within 2 minutes. Even when specifically targeting a machine with nvme drives.
I also played around with the memory allocation setting which didn’t seem to make a difference.
Example:
- name: SonarQube Scan
uses: sonarsource/sonarqube-scan-action@master
env:
SONAR_TOKEN: ${{ secrets.XXX }}
SONAR_HOST_URL: ${{ vars.XXXX }}
SONAR_SCANNER_OPTS: -Xmx16384m
In my PR I only added a comment line in the sonar-project.properties file.
Currently my assumption is that:
- my test is somehow flawed => No actual code touched so scan everything?
- there is some caching of files that messes things up. Are there some folder I can check and try to delete before the scan starts?
- It is somehow comparing to the wrong branch, triggering a full scan? We use develop (MAIN BRANCH), master, release_…
But even on the normal PR’s I see mostly long running javaSensor times:
INFO: Sensor JavaSensor [java] (done) | time=1479567ms
Hey,
In order to see the settings applied during the scan could you also share the full analysis logs?
Thanks,
Gyula
Hey,
Unfortunately, I still cannot reproduce the slow running time on my side. When testing with the provided IR files, the javabugs sensor finishes within 4 minutes in my tests, and when looking at the debug logs (both provided in a private message), I do not see anything out of the ordinary.
Also, note that a running time of ~40 minutes is in alignment with our performance goals for a project of this size for a full analysis. We have plans to improve our performance for code change analyses in the future, however, I cannot give a timeline for this yet.
Thank you for your investigation and your time. I will try some other things on our end to see if they have an impact. If so, I will update this topic.
Always good to hear you are working on performance improvements. Looking forward to the next LTS release!
1 Like
What fixed our performance issues automagically was upgrading our codebase to java17.
Since then, the soanrqube scanner with github workflow action works as advertised.
1 Like