Context
다음은 대부분의 중간 규모의 조직에서 활용 가능한 공통적인 하드웨어 권장 사항입니다:
App ESXi Server Configuration | DB ESXi Server Configuration |
|---|---|
|
|
다음과 같은 2개의 가상버신(Virtual Machine, VM)을 생성해서 1개의 VM은 SonarQube Server, 다른 1개의 VM은 두개의 ESXi 6.0 서버에서 SonarQube 데이터베이스로 사용합니다:
App VM Server Configuration | DB VM Server Configuration |
|---|---|
|
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.