하드웨어 권장 사양

Database

많은 인스턴스들을 관리하는 SonarQube 서버 인스턴스의 경우, SonarQube가 사용할 데이터베이스는 물리적으로 분리된 머신에 설치할 것을 권장합니다. 다만 네트워크 관점에서는 가까운 위치에 있는 서버를 사용하는 것이 좋습니다.

MS SQL

MS SQL 데이터베으스 공유 잠금 정책(shared lock strategy)은 SonarQube 실행시간에 영향을 미칩니다.

"is_read_committed_snapshot_on" 속성 값을 true로 설정해 심각한 부하 발생 상황에서 SonarQube가 잠재저긴 데드락(deadlock)에 걸리지 않도록 합니다. 

SELECT is_read_committed_snapshot_on FROM sys.databases WHERE name='YourSonarQubeDatabase';

ALTER DATABASE 'YourSonarQubeDatabase' SET READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK IMMEDIATE;

Oracle

SonarQuabe Server를 Linux 운영체제에서 실행하고, 데이터베이스로 Oracle를 사용하는 경우, /dev/random 때문에 Oricle JDBC 드라이버가 블럭될 수 있습니다. 이 문제의 해결과 관련된 더 자세한 정보는 http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty/(영문)을 참조합니다.

SonarQube 웹 서버의 JVM 파라미터(sonar.web.javaOpts)를 설정해, 이 문제를 해결할 수 있습니다:

-Djava.security.egd=file:///dev/urandom

Elasticsearch (a.k.a ES)

SonarQube는 백그라운드의 SearchServer 프로세스에서 Elasticsearch를 사용합니다. SonarQube의 성능을 향상하기 위해, ES 사용과 관련된 권장 설정을 사용할 것을 권장합니다.

자바 가상 머신(JVM)

• 실행 중에 heal 메모리의 사이즈가 변경되는 것(이는 매우 비용이 큰 프로세스입니다)을 방지하기 위해 min, max 메모리를 동일하게 설정할 것을 권장합니다. sonar.search.javaOps 속성의 -Xms 및 -Xmx을 참고합니다.

디스크(Disk)

• 디스크는 ES에서 병목이 되기 가장 쉽습니다. SSD는 회전에 기반한 다른 모든 물리적인 디스크에 비해 높은 성능을 얻을 수 있습니다. SSD를 장착한 머신에서는 보다 향상된 쿼리 및 인덱스 성능을 얻을 수 있습니다. 회전에 기반한 물리적인 디스크를 사용해야 하는 경우, 가급적 빠른 디스크를 선택하십시오(높은 퍼포먼스의 서버 디스크는 15000rpm의 성능을 냅니다).

• SonarQube 서버가 설치된 머신이 열 수 있는 파일 디스크립터(file descriptor)의 수를 늘리십시오. 32k 혹은 64k로 설정할 것을 권장합니다. 잣한 정보는 https://www.elastic.co/guide/en/elasticsearch/reference/current/setup-configuration.html#file-descriptors를 참조합니다.

• RAID 0을 사용하면 디스크 매체에 관계없이 성능을 향상할 수 있습니다. RAID가 제공하는 미러링(mirroring) 혹은 부분 변경(partial variants) 기능을 사용할 필요는 없습니다. Elasticserarch가 프라이머리 저장소 데이터를 복제합니다.
  

• 원격 마운트 스토리지(NFS, SMB/CIFS 혹은 NAS 등)를 사용하지 마십시오. 해당 저장소들은 매우 속도가 느리며, 평균 속도의 편차가 크고, 분석과정에서 실패의 주요 원인이 될 수 있습니다.
• 고급: SSD를 사용하는 경우, 운영체제의 I/O 스케줄러가 정상적으로 설정되었는지 확인합니다. 디스크에 데이터를 기록하는 경우, I/O 스케줄러는 데이터가 디스크로 실제로 전잘되는 시점을 결정합니다. 대부분의 *nix 계열의 운영체제에서 사용하는 스케줄러는 ctq(Completely Fair Queuing)입니다. 이 스케줄러는 각 프로세스에 "타임 슬라이스(time slice)"를 할당하고, 이 다양한 큐의 내용을 디스크로 전달하는 과정을 최적화합니다. 그리고 이 스케줄러는 회전 기반의 미디어에 최적화되어 있습니다: 즉, 플래터의 회전 특성에 따라, 디스크의 물리적인 레이아웃에 기반하여 프로세스를 최적화합니다. SSD는 플래터를 가지고 있지 않으므로, 이 최적화 기법은 매우 비효율적입니다. 대신 데드라인(deadline) 혹은 눕(noop)을 사용해야 합니다. 데드라인 스케줄러는 프로세스가 지연된 시간에 기반해 프로세스를 최적화하며, 눕 스케줄러는 FIFO(First-In, First-Out) 큐 방식에 기반해 프로세스를 최적화합니다. 이 단순한 변화로 인한 효과는 매우 극적인 영향을 미칩니다.

• 고급: SonarQube 홈 디렉토리를 느린 디스크에 설정한 경우, sonar.path.data 속성을 설정해 데이터를 더 빠른 디스크(RAID 0 local SSD 등)로 이동시킬 수 있습니다.

메모리(Memory)

• 운영체제가 사용 가능한 머신의 메모리는 최소한 Elasticsearch heap 사이즈 보다 커야 합니다. ES이 사용하는 루씬(Lucene)은 인-메모리 데이터 스트럭처 캐싱을 위해 운영체제를 레버리지하도록 설계되어 있습니다. 즉, 운영체제는 최소한 1Gb 잏상의 가용 메모리를 가지고 있어야 합니다.

• 32Gb 이상의 메모리를 할당하지 마십시오.

• 보다 자세한 설명은 http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/heap-sizing.html를 참조합니다.

• 고급: Elasticsearch는 하이브리드 mmapfs / niofs 디렉토리를 사용해 인덱스를 저장합니다. 기본 운영체제에서 mmap 카운트를 낮게 제한하고 있는 경우에는 아웃 오브 메모리 익셉션이 발생할 수 있습니다. Linux 운영체제를 사용하는 경우, root 게정으로 다음 명령어를 수행하여 해당 제한치를 증가시킬 수 있습니다:
  

  sysctl -w vm.max_map_count=262144

  이 값을 영구적으로 사용하고자 하는 경우, /etc/sysctl.conf의 vm.max_count 값을 업데이트합니다.

프로세서(CPU)

• 빠른 프로세서 혹은 다수의 프로세서 중 선택을 해야하는 경우에는 다수의 프로세서를 선택할 것을 권장합니다. 복수의 코어에서 동시 수행을 통해 분석하는 편이 보다 효과가 큽니다.
• 기본적으로 데이터는 다수의 노드에 분산되어 있으며, 처리 속도는 가장 느린 노드의 속도에 의존적입니다. 빠른 노드 하나 + 느린 노드 하나를 운영하는 것보다 평균적인 속도의 노드를 다수 운영하는 편이 효과적입니다.