配置sonar.properties后重启服务无效，Sonar分析报堆内存溢出

Hey there, let's work through these two SonarQube issues step by step—they're super common, so I’ve got some practical fixes to help you out!

Let's start with the basics first, since misconfiguration here usually boils down to a few easy-to-miss checks:

• Double-check the config file path
  SonarQube reads its core config from $SONARQUBE_HOME/conf/sonar.properties by default. Make sure you’re editing the file in this exact directory—many folks accidentally modify a copy or a file in the wrong location. Verify with a quick command:

  # Linux/macOS
  cat $SONARQUBE_HOME/conf/sonar.properties | grep "sonar.web.javaOpts"
  

  For Windows, navigate to your SonarQube installation folder, open the conf directory, and confirm you’re editing the correct sonar.properties file.

• Fix syntax typos in your parameters
  I noticed a typo in your sonar.ce.javaOpts line: you wrote HeapDumpOnOutOfMemoryErro (missing the final r). Typos like this cause SonarQube to ignore the entire parameter line, so fix that first.

• Ensure a full service restart
  Sometimes SonarQube doesn’t shut down completely, leaving old processes running with the original config. Do a clean restart:

  # Linux (systemd)
  systemctl stop sonarqube
  ps aux | grep sonar  # Kill any remaining Sonar-related processes if needed
  systemctl start sonarqube
  

  For Windows, use the Services manager to stop the SonarQube service, wait 10 seconds, then start it again.

• Verify via startup logs
  Check the logs in $SONARQUBE_HOME/logs (web.log, ce.log, search.log) after restarting. Search for your -Xmx6144m parameter—if you don’t see it in the logs, the config file isn’t being read, so go back to checking the file path.

Once you’ve fixed the typo from the first issue, let’s tackle the OOM problem with these additional checks:

• Clear UI-based JVM config overrides
  SonarQube prioritizes config stored in its database (set via the UI) over the sonar.properties file. Even if you think you haven’t enabled UI config, it’s worth checking:

  1. Log into your SonarQube admin dashboard
  2. Go to Administration > Configuration > General Settings > Java Virtual Machine Settings
  3. Check the Web Server, Compute Engine, and Elasticsearch sections—if any have pre-filled JVM parameters, delete them and save
  4. Restart SonarQube, and it will now use the values from sonar.properties

• Confirm JVM parameters are applied to processes
  To make sure your settings are actually being picked up by the SonarQube processes:

  # Linux/macOS: Find the web process and check its flags
  ps aux | grep sonar.web
  # Or use jinfo for detailed JVM flags (replace <pid> with the process ID)
  jinfo -flags <pid>
  

  For Windows, use Task Manager or Process Explorer to inspect the SonarQube Java processes’ startup arguments—look for your -Xmx6144m value.

• Check Elasticsearch memory constraints
  SonarQube’s Search component runs on Elasticsearch, which has strict memory limits: it won’t allow heap memory to exceed 50% of your server’s physical RAM (or 32GB, whichever is smaller). If your server has less than 12GB of RAM, setting -Xmx6144m won’t work—Elasticsearch will auto-adjust to a safe value. Make sure your server has enough physical memory to support your desired heap size.

• Inspect custom startup scripts
  If you’ve modified the default startup scripts (like sonar.sh or StartSonar.bat), they might be hardcoding JVM parameters that override sonar.properties. Open the script in your $SONARQUBE_HOME/bin/<your-os> directory and search for variables like SONAR_WEB_JAVAOPTS—if there are hardcoded values, remove them to let the config file take precedence.

内容的提问来源于stack exchange，提问作者lanny8588