SonarQube Version : Enterprise Edition v2025.1 (102418) SonarQube Deployment : Kubernetes SonarScanner CLI Version : 7.0.2.4839
We have a large C++ scan which fails with an Error 137 Out Of Memory Error. We have tried setting SONAR_SCANNER_JAVA_OPTS="-Xmx15g", however, there seems to be a 7GB max on the scanner memory. From the log:
Scanner max available memory: 7 GB
...
JVM max available memory: 15 GB
I can not see anything in the CLI documentation about this setting this Max Scanner Memory value. It seems to be a restriction on SonarCloud, from what I can see from other posts, but we are running on-prem.
I can see that the logs are a bit unclear—let me clarify what’s happening. When you run the scanner, there are actually two separate processes involved:
The Scanner Bootstrapper: This component initializes the scanning process. Its memory usage is determined by SONAR_SCANNER_OPTS, which controls the maximum memory available to the bootstrapper itself (displayed as Scanner max available memory).
The Actual Scanning Process: This is the primary process handling the code analysis. Its memory usage is controlled by SONAR_SCANNER_JAVA_OPTS (displayed as JVM max available memory).
Based on what you’ve said, your memory issue is occurring in the actual scanning process, not the bootstrapper. So adjusting SONAR_SCANNER_JAVA_OPTS should have the desired effect, rather than changing SONAR_SCANNER_OPTS.
If you could provide additional logs from around the time the memory failure occurs, I’d be happy to help you further troubleshoot the issue!
Thanks @Colin for the response. That is good information. We did set SONAR_SCANNER_JAVA_OPTS="-Xmx15g", which is how we got to 15GB in the log. Maybe it might be helpful to update the Troubleshooting section in the Scanner CLI docs, SonarScanner CLI | SonarQube Server Documentation ?
I think we have mitigated this for now. We found that the scanner was using a thread count of 48 for CFamily analysis, which is what it determined as the max count for the VM, however, when it did use all threads it overloaded the memory for the container the scan was running in. We have set the max thread count to 8, for now, and scans are successful again. We will continue to tune the thread count and memory, as well.