在这篇文章中，我想分享我的经验和技巧，以了解如何正确设置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
- 磁盘利用率
更多点击标题见原文。