高级硬件建议

数据库

我们建议，对于大型实例，SonarQube 使用的数据库托管在物理上与 SonarQube Server 分离但在网络上靠近它的计算机上。

甲骨文

如果您的 SonarQube 服务器在 Linux 上运行并且您使用的是 Oracle，则 Oracle JDBC 驱动程序可能会由于/dev/random.  

为了避免这种情况，您可能需要将此 JVM 参数添加到您的 SonarQube Web 服务器 ( sonar.web.javaOpts) 配置中：

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

弹性搜索

•  SonarQube 在后台使用Elasticsearch 。为了确保 SonarQube 的良好性能，您需要遵循与 ES 使用相关的这些建议。

磁盘

• 可用磁盘空间是绝对要求。ES 实现了一种安全机制来防止磁盘被索引数据淹没，当达到 95% 磁盘使用水位线时，会将所有索引锁定为只读模式。有关从 ES 只读索引恢复的信息，请参阅 故障排除 页面。

• 磁盘访问很容易成为ES的瓶颈。如果您买得起 SSD，它们远远优于任何旋转介质。SSD 支持的节点的查询和索引性能均得到提升。如果您使用旋转介质，请尝试获得尽可能快的磁盘（高性能服务器磁盘 15,000 RPM 驱动器）。

• 对于旋转磁盘和 SSD 来说，使用 RAID 0 是提高磁盘速度的有效方法。由于 Elasticsearch 副本和数据库主存储，无需使用 RAID 的镜像或奇偶校验变体。

• 请勿使用远程安装的存储，例如 NFS、SMB/CIFS 或网络附加存储 (NAS)。它们通常速度较慢，显示的延迟较大，平均延迟偏差较大，并且是单点故障。

先进的

• 如果您使用 SSD，请确保操作系统 I/O 调度程序配置正确。当您将数据写入磁盘时，I/O 调度程序会决定何时将数据实际发送到磁盘。大多数 Unix 发行版默认是一个名为 CFQ（完全公平队列）的调度程序。该调度程序为每个进程分配“时间片”，然后优化这些不同队列到磁盘的交付。它针对旋转介质进行了优化：旋转盘片的性质意味着基于物理布局将数据写入磁盘的效率更高。然而，这对于 SSD 来说效率非常低，因为不涉及旋转盘片。相反，应该使用截止日期或 NOOP。截止时间调度程序根据写入等待的时间进行优化，而 NOOP 只是一个简单的 FIFO 队列。这个简单的改变可以产生巨大的影响。

• 如果 SQ 主目录位于慢速磁盘上，则该属性 sonar.path.data 可用于将数据移动到更快的磁盘（例如 RAID 0 本地 SSD）。

记忆

• 建议您将 50% 的可用内存分配给 Elasticsearch 堆，同时保留其余 50% 的空闲内存。原因是 Lucene（ES 使用）旨在利用底层操作系统来缓存内存中的数据结构。

• 这意味着默认情况下操作系统必须至少有 1GB 可用内存。 

• 不要分配超过 32GB。 

• 有关更多详细信息，请参阅以下 Elasticsearch 文章：

• Elasticsearch 指南：堆大小调整

• 一大堆麻烦

• Elasticsearch 参考：JVM 堆大小

中央处理器

• 如果您需要在更快的 CPU 或更多内核之间进行选择，请选择更多内核。多核提供的额外并发性将远远超过稍快的时钟速度。

• 从本质上讲，数据分布在多个节点上，因此执行时间取决于最慢的节点。拥有多个中型盒子比一快一慢要好。