This is an archived version of the documentation for SonarQube-7.3.
See the Latest Documentation for current functionality.

Benchmark

Context

The following figures have been produced on common hardware available in most of mid-size companies :

App ESXi Server Configuration

DB ESXi Server Configuration

  • 2* Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (32 VCPUs)

  • 128 GB RAM

  • 1.9 TB volume (RAID5 of 8 Hard Drives of 300GB SAS 15K)

  • 2*1 GB NICs

  • ESXi 6.0

  • 2* Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (32 VCPUs)

  • 128GB RAM

  • 1.9TB volume (RAID5 of 8 hard drives of 300GB SAS 15k)

  • 2*1 GB NICs

  • ESXi 6.0

We created 2 VMs, one for SonarQube Server, one for SonarQube Database inside two ESXi 6.0 Servers :

App VM Server Configuration

DB VM Server Configuration

  • 8 VCPUs

  • 16 GB RAM

  • 20 GB storage for system + 200 GB storage for data (LVM) (RAID5 of 8 hard drives of 300GB SAS 15k)

  • 1 GB NIC

  • CentOS 7 64bits

  • 4 VCPUs

  • 8 GB RAM

  • 20 GB storage for system + 200 GB storage for data (LVM)

  • 1 GB NIC

  • CentOS 7 64bits

MySQL 5.6.27 (Oracle Community Edition)

Goals

With SonarQube 5.2+ there is no longer Source Lines indexation done by the SearchServer, so quantity of code you are going to analyze will not affect the performance of the SearchServer.

By running this benchmark, we wanted to validate the number of Millions of Issues a given hardware hosting SonarQube can support.

  • can SonarQube digest millions of Issues and how many time does it take ?

  • can we still use the UI of SonarQube with these millions of Issues into it ?

Results

Indexation Throughput

Issues Indexation done by the Search Server is not linear :

Millions of Issues

Indexation Time (in hours)

25

1

60

2-3

100

6-7

RAM to Allocate to SearchServer

RAM to allocate to the SearchServer so to ElastSearch is linear according to the number of Issues :

Millions of Issues

SearchServer RAM in GB

25

4

60

7

100

12

SearchServer's RAM can be configured in sonar.properties using : sonar.search.javaOpts

SearchServer’s RAM has to be more or less equal to : Size of ‘es' directory + 1 GB

CPU Allocation

With SonarQube 5.2+, the SearchServer is configured to use 5 ElasticSearch Primary Shards. This allows SonarQube to handle by default 50 Millions of Issues on a server having at least 4 CPU Cores dedicated to the SearchServer.

Millions of Issues

# Shards

# Cores

50

5

4

default configuration

30

3

2

Shards configuration must be adjusted according to the quantity of Issues you have to manage. The rule is to have 1 Shard by block of 10M Issues. So for 100M Issues, you need 10 Shards, so at least 9 Cores.