Prerequisites and Overview
Prerequisite
The only prerequisite for running SonarQube is to have Java (Oracle JRE 11 or OpenJDK 11) installed on your machine.
Hardware Requirements
- A small-scale (individual or small team) instance of the SonarQube server requires at least 2GB of RAM to run efficiently and 1GB of free RAM for the OS. If you are installing an instance for a large teams or Enterprise, please consider the additional recommendations below.
- The amount of disk space you need will depend on how much code you analyze with SonarQube.
- SonarQube must be installed on hard drives that have excellent read & write performance. Most importantly, the "data" folder houses the Elasticsearch indices on which a huge amount of I/O will be done when the server is up and running. Great read & write hard drive performance will therefore have a great impact on the overall SonarQube server performance.
- SonarQube does not support 32-bit systems on the server side. SonarQube does, however, support 32-bit systems on the scanner side.
Enterprise Hardware Recommendations
For large teams or Enterprise-scale installations of SonarQube, additional hardware is required. At the Enterprise level, monitoring your SonarQube instance is essential and should guide further hardware upgrades as your instance grows. A starting configuration should include at least:
- 8 cores, to allow the main SonarQube platform to run with multiple Compute Engine workers
- 16GB of RAM For additional requirements and recommendations relating to database and ElasticSearch, see Hardware Recommendations.
Supported Platforms
Java
SonarQube scanners require version 8 or 11 of the JVM and the SonarQube server requires version 11. Versions beyond Java 11 are not officially supported.
SonarQube is able to analyze any kind of Java source files regardless of the version of Java they comply to.
We recommend using the Critical Patch Update (CPU) releases.
Java | Server | Scanners |
---|---|---|
Oracle JRE | ||
OpenJDK | ||
Database | |
---|---|
PostgreSQL | |
Microsoft SQL Server | |
Latin1_General_CS_AS ) | |
READ_COMMITTED_SNAPSHOT must be set on the SonarQube database to avoid potential deadlocks under heavy load | |
Oracle | |
NLS_CHARACTERSET ) | |
Web Browser
To get the full experience SonarQube has to offer, you must enable JavaScript in your browser.
Browser | |
---|---|
Microsoft Internet Explorer | |
Microsoft Edge | |
Mozilla Firefox | |
Google Chrome | |
Opera | |
Safari |
ALM Integrations
Azure Devops Server
The SonarScanner for Azure Devops is compatible with TFS 2017 Update 2 and greater
Bitbucket Server
To add Pull Request analysis to Code Insights in Bitbucket Server, you must be running Bitbucket Server version 5.15+.
GitHub Enterprise and GitHub.com
To add Pull Request analysis to Checks in GitHub Enterprise, you must be running GitHub Enterprise version 2.15+.
GitHub.com is also supported.
GitLab Self-Managed and GitLab.com
To add Merge Request Decoration to your Merge Requests in GitLab Self-Managed, you must be running Gitlab Self-Manged 11.7+.
GitLab.com is also supported.
Platform notes
Linux
If you're running on Linux, you must ensure that:
vm.max_map_count
is greater than or equal to 524288fs.file-max
is greater than or equal to 131072- the user running SonarQube can open at least 131072 file descriptors
- the user running SonarQube can open at least 8192 threads
You can see the values with the following commands:
sysctl vm.max_map_count
sysctl fs.file-max
ulimit -n
ulimit -u
You can set them dynamically for the current session by running the following commands as root
:
sysctl -w vm.max_map_count=524288
sysctl -w fs.file-max=131072
ulimit -n 131072
ulimit -u 8192
To set these values more permanently, you must update either /etc/sysctl.d/99-sonarqube.conf (or /etc/sysctl.conf as you wish) to reflect these values.
If the user running SonarQube (sonarqube
in this example) does not have the permission to have at least 131072 open descriptors, you must insert this line in /etc/security/limits.d/99-sonarqube.conf (or /etc/security/limits.conf as you wish):
sonarqube - nofile 131072
sonarqube - nproc 8192
If you are using systemd
to start SonarQube, you must specify those limits inside your unit file in the section [service] :
[Service]
...
LimitNOFILE=131072
LimitNPROC=8192
...
seccomp filter
By default, Elasticsearch uses seccomp filter. On most distribution this feature is activated in the kernel, however on distributions like Red Hat Linux 6 this feature is deactivated. If you are using a distribution without this feature and you cannot upgrade to a newer version with seccomp activated, you have to explicitly deactivate this security layer by updating sonar.search.javaAdditionalOpts
in $SONARQUBEHOME/conf/sonar.properties_:
sonar.search.javaAdditionalOpts=-Dbootstrap.system_call_filter=false
You can check if seccomp is available on your kernel with:
$ grep SECCOMP /boot/config-$(uname -r)
If your kernel has seccomp, you will see:
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_SECCOMP=y
For more detail, see the Elasticsearch documentation.
Fonts
Generating Executive Reports requires that fonts be installed on the server hosting SonarQube. On Windows servers, this is a given. However, this is not always the case for Linux servers.
The following should be ensured:
- Fontconfig is installed on the server hosting SonarQube
- A package of FreeType fonts is installed on the SonarQube server. The exact packages available will vary by distribution, but a commonly used package is
libfreetype6