I’m having a lot of troubles with the new 10.8 version. It seems that the required Java Memory for all the processes is now very high.
We were running the 10.7 version with default parameters for JVM and now it is not possible. We have had to increase the memory to 8Gb (for both compute engine and web server) and still the performance is slow.
I have cut all the TRACE information that doesn’t belong to the request that is causing the java heap error.
This is the issue:
### Error querying database. Cause: org.postgresql.util.PSQLException: Ran out of memory retrieving query results.
I don’t know exactly what is doing the request (I just clicked on the project and it should display the project home overview page) but as you can see in the SQL it seems that it fails trying to retrieve the list of pull request for that project. I suppose it should display the branch selection combo with those values.
I have checked the project and it has around 150 pull requests. This request was working perfectly on 10.7 with just 512Mb on the JVM for the Web process.
Now we have to increase the memory up to 8Gb for the Web process in order to make it work.
I don’t know what could be the problem but somehow now this request is trying to get ALL the measures for ALL the pull requests of the project when just going to the home page. Knowing that the dependency check plugin was installed it may be trying to get all the measures including the html report for all the pull requests.
Seems to be related to the changes in the “live_measures” table.
Let me know what you think and if you need any additional information.
Interestingly the issue seem to come from Postgres itself. Ran out of memory retrieving query results. indicates an issue on the database side, not the SonarQube instance.
It’s interesting that this request is taking up more memory than before, so I’ve flagged this for attention. In the meantime, I’d be really interested to know how much memory is available to your Postgres database.
We’ve indeed made some changes in the way we retrieve pull request data in 10.8 (more details here: SONAR-22870). We didn’t expect it to use so much memory on Postgres’ side that some users would be negatively impacted.
I’ve reached out to the team that made the changes for more information, but in the meantime, can you tell us how much memory Postgres has and whether giving it some more memory solves the issue?
Yes, it is executing the query but it is on client side, it is the JDBC driver failing on the JVM with OutOfMemory.
If it wasn’t the client side then why if we increase the Web JVM heap it works? It doesn’t make sense. We are not changing anything on database side, just giving the JVM more memory (much more than before) and then it works.
Looking a the SQL a little bit more, the query that fails is trying to get data from “measures” table. And it tries to get the colum “m.json_value as jsonValue”, that is the new value where ALL measures are stored for a giving component and branch/PR.
I’m not sure and I don’t know the code but for me it doesn’t make sense to query ALL measures just to get a list of pull request for a given project.
Just my two cents
Thank you and please let me know if you find what is causing this!
If you had the plugin, just disabling it won’t instantly solve the issue, as the measures will still be there until the next analysis. As you analyse more and more pull requests and there is no longer the very large measures from the plugin, the memory usage will get back to normal.
Yes, I know. But the issue seems to be that it is trying to load ALL the measures and not only the main branch or the branch selected. There shouldn’t be any problem with the Dependency Check html report if it is just one measure. The trouble is when trying to get 150 reports…
Hello @acalero,
The next SQ release will include an improvement to reduce the number of measures loaded in memory simultaneously. More details are in the ticket.
Release 2025.1 doesn’t fix the problem, at least for us.
We were testing with different memory setting for web and ce. We stopped at:
sonar.web.javaOpts=-Xmx70g -Xms5g
sonar.ce.javaOpts=-Xmx40g -Xms5g
There is no more OOM errors, the application hangs few minutes after start.
Hello @pkrajewski,
Is it hanging when you are going to a project overview page? Could you please share your server logs so we can see where it is hanging? Thank you.
The 2025.1.1 patch release will include a change in the upgrade migration to prevent the migration of large measures (like the report from the depdendency-check plugin). It should be released within a couple of weeks.
Note that if that solves your issue, you should stop loading the sonar.dependencyCheck.htmlReportPath analysis property for every branch otherwise the issue will come back.
