Recently i’ve reached the OOM uncle on my 64gb system and started some digging. While Sonar was not the cause or a considerable reason of it, i found out that its IDEA integration was consuming 4g of resident memory. What’s even more concerning, when i’ve launched my second IDE while the first one was still running (i’m working / playing with multiple languages, so it’s regular to have several JB IDE side by side), it has spawned another SonarLint process (but i bet the first one could have been easily reused). It’s a pain to see that an IDE extension may consume more than IDE itself.
I definitely want to stick with Sonar to have something to give a judging look to anyone who leaves files with yellow highlights, so i’m not going to disable it, but i think it’s quite challenging to have it running on low-resource systems. Even on my obese laptops with 32g it can become a thing that i can’t sustain (my development environment requires a lot of similar things running). I guess most of the people work with something like 16g, and it’s quite a player in the RAM battle, so my suggestions are simple:
Set smaller memory limits by default or let the user set them in configuration. I prefer my linters choking in GC loops to waking up OOM guard that will tear down half the system
Add a button somewhere in the IDE to stop (and start) the server, so that users can free up resources in the moments of need
Check if there is a server running, and if that’s the case, just reuse that server.
Right now i see two instances on in my process list that eat 1g of RAM (maybe my memory just plays with me saying that there were 4g instances? at the same time, i see only Xms set), but still, i think having one instance for all IDEs instead of one would be quite fantastic.
First of all I totally agree it would be great to reuse the single backend process for the SonarQube for IDE instead of spawning new ones. Unfortunately it’s not one of the closest priorities, but it’s definitely on our radar.
Second, regarding your memory consumption problem. Clarification question:
Is your SonarQube for IDE instance connected to SonarQube server? We are aware about excessive usage of the RAM when connected to server during synchronization. But as far as I know it happens when on server there are many Taint Issues (dozens of thousands) or really a lot regular issues (above 100k).
So please confirm it’s your case. And if it’s not - your SonarQube for IDE is not connected to Sonar server or you don’t have excessive amount of issues to sync - please let me know. I’m very interested to know more about your situation in this case.
Hey, I’m using SonarLint plugin for JB products with no backing server. I don’t think that my codebase is anything special or giant in terms of lines / expressions / violations, my regular work goes over just a couple of relatively simple services, no monorepos or hundreds of thousands of violations… I’ve also hasn’t ever triggered full project scan manually, and this experience must have came in through regular coding and fixing the highlights, but i’m also a person whose IDE can easily run for a couple of weeks or even months before restarting one way or another.
OK, so as I get it, main problem is several SonarQube IDE backend instances that have unreasonable memory footprint instead of sharing one backend for many IDEs.
We will try to address it, but it’s to the closest priority, unfortunately.
Speaking about individual footprint of the single process - 1G RAM is pretty common memory footprint for SonarQube IDE so it will be not easy to significantly push it down. Also, sometimes if there is enough RAM space on OS overall, operating system tend not to take back the space that was given to the process even if process don’t need it anymore. This way if at some moment during analysis 2-3G of RAM was utilized - it may show this number for a long time. So overtime, long living process can increase memory footprint visible in OS monitoring tool, but looking from inside of JVM it will show that significantly less memory is required now.
So in case you don’t run out of OS RAM, you may observe it, given you don’t restart your IDEs for a long time.
Also we going to optimize many neighboring aspects, that hopefully will affect the overall memory usage in a positive way.