在生产中运行Elasticsearch的深入指南 – TechNotes

20-02-24 banq

在这篇文章中,我想分享我的经验和技巧,以了解如何正确设置Elasticsearch并避免常见的陷阱。

基础知识:集群,节点,索引和分片

我想先解释一些基本概念。本节将完全不介绍最佳实践,而主要侧重于解释术语。大多数人可能会跳过此步骤。

Elasticsearch是用于运行Apache Lucene(基于Java的搜索引擎)的分布式安装的管理框架。Lucene实际上是保存数据并进行所有索引和搜索的地方。ES位于此之上,使您可以并行运行数千个Lucene实例。

ES的最高级别单元是群集。集群是ES 节点 和索引的集合。

1.尽量使用堆,但堆大小不得超过30G

这是一个很多人都不知道的关于堆的秘密:堆中的每个对象都需要一个唯一的地址,即一个对象指针。该地址的长度是固定的,这意味着可以寻址的对象数量是有限的。这很重要的简短版本是,在某个时候,Java将开始使用压缩的对象指针而不是未压缩的对象指针。这意味着每个内存访问都将涉及其他步骤,并且速度会慢得多。您100%不想超过此阈值(大约32G)。

长话短说:如果感到幸运,请使用29G的RAM或30的RAM,请使用XFS,并尽可能使用hardwareprefetch和llc-prefetch。

2.FS缓存

大多数人在Linux上运行Elasticsearch,Linux使用RAM作为文件系统缓存。常见的建议是将64G用于ES服务器,这样的想法是一半缓存,一半堆。我尚未测试FS缓存。但是,不难看出,大型ES群集(如用于日志记录)可以从拥有大型FS缓存中受益匪浅。如果您所有的索引都适合放入堆,则不会那么多。

3. CPU

如果您进行大量索引编制,则与仅执行日志记录相比,您需要更多,更快的CPU。对于日志记录,我发现8个内核绰绰有余。

4.磁盘

首先,如果索引适合RAM,则磁盘仅在节点冷启动时才重要。其次,实际可以存储的数据量取决于索引布局。每个分片都是Lucene实例,它们都有内存需求。这意味着您可以在堆中容纳最大数量的分片。

通常,您可以将所有数据磁盘放入RAID0。您应该在Elasticsearch级别进行复制,因此丢失节点无关紧要。请勿将LVM与多个磁盘一起使用,因为LVM一次只能写入一个磁盘,根本就不会给您带来多个磁盘的好处。

关于文件系统和RAID设置,我发现以下内容:

  • Scheduler:cfq和截止日期优于noop。如果您有nvme,但我还没有测试过,Kyber可能会很好
  • QueueDepth:尽可能高
  • Readahead:需要
  • Raid chunk size:无影响
  • FS块大小:无影响
  • FS类型:XFS> ext4

5.分片

精简版:

  • 对于写入繁重的工作负载,主分片=节点数
  • 对于读取繁重的工作负载,主分片*副本=节点数
  • 更多副本=更高的搜索性能

公式:node_throughput*number_of_primary_shards

如果要优化搜索性能,可以通过以下公式给出搜索性能:

node_throughput*(number_of_primary_shards + number_of_replicas)

对于搜索,主分片和副本分片基本上是相同的。因此,如果您想提高搜索性能,只需增加副本数即可。

6. 索引大小

30G堆=每个节点最多140个分片

使用超过140个分片,会使Elasticsearch进程崩溃并出现内存不足错误。这是因为每个分片都是Lucene实例,并且每个实例都需要一定数量的内存。这意味着每个节点可以有多少个分片。

如果您有节点数量,分片数量和索引大小,则可以计算容纳多少个索引:

number_of_indices = (140 * number_of_nodes) / (number_of_primary_shards * replication_factor)

根据您的磁盘大小,您可以轻松地计算出索引的大小:

index_size = (number_of_nodes * disk_size) / number_of_indices

但是,请记住,较大的索引也较慢。对于日志记录来说,一定程度是可以的,但是对于真正搜索繁重的应用程序,您应该根据所拥有的RAM数量来增加大小。

7. 段合并

请记住,每个段都是文件系统上的实际文件。更多的细分=更多的阅读开销。基本上,对于每个搜索查询,它都转到索引中的所有分片,再从那里到分片中的所有段。拥有许多段会极大地增加群集的读取IOPS,直至无法使用为止。因此,最好将段数保持在尽可能低的水平。

有一个force_merge API,它允许您将段合并到一定数量,例如1。如果进行索引轮换,例如,因为您使用Elasticsearch进行日志记录,则在不使用群集时进行常规强制合并是一个好主意。强制合并会占用大量资源,并且会大大降低群集的速度。因此,最好不要让Graylog为您做到这一点,但是当集群使用较少时,您可以自己做。如果您有很多索引,则肯定要这样做。否则,您的群集将缓慢爬行到停止状态。

8.集群布局

对于除最小设置以外的所有内容,最好使用专用的符合主机资格的节点。主要原因是您应始终具有2n + 1个符合主机资格的节点以确保仲裁。但是对于数据节点,您只希望能够随时添加一个新节点,而不必担心此要求。另外,您也不希望数据节点上的高负载影响您的主节点。

最后,主节点是种子节点的理想候选者。请记住,种子节点是您在Elasticsearch中执行节点发现的最简单方法。

主节点可能很小,一个CPU核甚至4GRAM足以满足大多数群集的需求。与往常一样,关注实际使用情况并进行相应调整。

9.监控方式

我喜欢监视,也喜欢监视Elasticsearch。ES为您提供了大量的指标,并且以JSON的形式为您提供所有指标,这使得传递给监视工具非常容易。以下是一些有用的监视内容:

  • 段数
  • 堆使用
  • 堆GC时间
  • 平均 搜索,索引,合并时间
  • IOPS
  • 磁盘利用率

更多点击标题见原文。

 

         

猜你喜欢