Elasticsearch 性能优化指引（十八）

清疚 2022-12-13 14:18 149阅读 0赞

Elasticsearch 性能有时需要优化，以提高效率，具体有哪些方案呢？下面我们一一详解。

**1、合并请求**

为了获得更快的索引速度，你能做的一项优化是通过批量  API, 一次发送多个 命令进行操作。这个操作将节省网络来回的开销，并产生更大的索引吞吐量。一 个单独的批量可以接受任何索引操作。

**2、优化 Lucene 分段的处理**

一旦  Elasticsearch  接收到了应用所发送的文档，它会将其索引到内存中称为 分段( segments ) 的倒排索引。这些分段会不时地写入磁盘。这些分段是不能改变 的，只能被删除，这是为了操作系统更好地缓存它们。另外，较大的分段会定期 从较小的分段创建而来, 用于优化倒排索引，使搜索更快。 有很多调节的方式来影响每一个环节中 Elasticsearch  对于这些分段的处理， 根据你的使用场景来配置这些，常常会带来意义重大的性能提升。本篇将讨论这 些调优的方式，可以将它们分为以下 3  类。

■刷新 (refresh ) 和冲刷 ( flush) 的频率——刷新会让  Elasticsearch  重新打开索 引，让新建的文档可用于搜索。冲刷是将索引的数据从内存写入磁盘。从性能的 角度来看，刷新和冲刷操作都是非常消耗资源的，所以为你的应用正确地配置它 们是十分重要的。

■合并的策略—— Lucene ( Elasticsearch  也是如此 ) 将数据存储在不可变的一 -组文件中，也就是分段中。随着索引的数据越来越多，系统会创建更多的分段。 由于在过多的分段中搜索是很慢的，因此在后台小分段会被合并为较大的分段， 保持分段的数量可控。不过, 合并也是十分消耗性能的，对于  I/O  子系统尤其如此。 你可以调节合并的策略，来确定合并多久发生一次，而且分段应该合并到多大。■存储和存储限流——  Elasticsearch  调节每秒写入的字节数，来限制合并 对于 I/O  系统的影响。根据硬件和应用，你可以调整这个限制。还有一些其他的 选项告诉 Elasticsearch  如何使用存储。例如，可以选择只在内存中存放索引。

**3、刷新和冲刷的阈值**

Elasticsearch  通常被称为近实时 ( 或准实时 ) 系统。这是因为搜索不是经常运 行于最新的索引数据之上( 这个数据是实时的 ) ，但是很接近了。打上近实时的标 签是因为通常 Elasticsearch  保持了某个时间点索引打开的快照，所以多个搜索会 命中同一个文件并重用相同的缓存。在这个时间段中，新建的文档对于那些搜索 是不可见的，直到你再次刷新。 刷新，正如其名, 是在某个时间点刷新索引的快照 , 这样你的搜索就可以命中 新索引的数据。这是其优点。其不足是每次刷新都会影响性能: 某些缓存将失效， 拖慢搜索请求，而且重新打开索引的过程本身也需要一些处理能力， 拖慢了索 引的建立。

**4、何时刷新**

默认的行为是每秒自动地刷新每份索引。你可以修改其设置 , 改变每份索引 的刷新间隔, 这个是可以在运行时完成的。例如，下面的命令将自动刷新的间隔 设置为了 5  秒。

put test1

\{  
  "settings": \{  
    " index. refresh\_ interval ": "5s"  
  \}  
\}

当增加  refresh\_ interval  的值时，你将获得更大的索引吞吐量，因为花费在 刷新上的系统资源更少了。 或者你也可以将 refresh\_ interval  设置为 \-1, 彻底关闭自动刷新并依赖手动刷 新。这对于索引只是定期批量变化的应用非常有效,如产品和库存每晚更新的零

售供应链。索引的吞吐量是非常重要的，因为你总想快速地进行更新，但是数据 刷新不一定是最重要的，因为无论如何都不可能获得完全实时的更新。所以每晚 你可以关闭自动刷新，进行批量的 bulk  索引和更新 , 完成后再进行手动刷新。 为了实现手动刷新，访问待刷新索引的 refresh  端点。

**何时冲刷**

对于  Elasticsearch  而言，刷新的过程和内存分段写入磁盘的过程是相互独立 的。实际上，数据首先索引到内存中，经过一次刷新后，Elasticsearch  也会地搜 索相应的内存分段。将内存中的分段提交到磁盘上的 Lucene  索引的过程，被称 为冲刷( flush) ，无论分段是否能被搜到，冲刷都会发生。 为了确保某个节点宕机或分片移动位置的时候，内存数据不会丢失， Elasticsearch 将使用事物日志来跟踪尚未冲刷的索引操作。除了将内存分段提交 到磁盘，冲刷还会清理事物日志， 满足下列条件之一就会触发冲刷操作。

■内存缓冲区已满。

■自上次冲刷后超过了一定的时间。

■事物日志达到了一定的阈值。

为了控制冲刷发生的频率，你需要调整控制这  3  个条件的设置。 内存缓冲区的大小在 elasticsearch.yml  配置文件中定义，通过  indices . memory . index\_buffer\_ size 来设置。这个设置控制了整个节点的缓冲区 , 其值可 以是全部 JVM  堆内存的百分比，如  10% ，也可以是  100 MB  这样的固定值。 事物日志的设置是具体到索引上的，而且同时控制了触动冲刷的规模( 通过 index . translog.flush\_ threshold\_ size )和多数索引设置一样 , 你可以在运行时修改 它们。

put test1

\{  
  "settings": \{  
    "index.translog.flush\_threshold\_size": "500mb"  
  \}  
\}

当冲刷发生的时候，它会在磁盘上创建一个或多个分段。执行一个查询的时 候, Elasticsearch( 通过  Lucene ) 查看所有的分段，然后将结果合并到一个整体的分 片中。关于分段，这里需要记住的关键点是你需要搜索的分段越多, 搜索的速度就 越慢。为了防止分段的数量失去控制，Elasticsearch ( 也是通过  Lucene ) 在后台将 多组较小的分段合并为较大的分段。

**5、JVM**  **堆和操作系统缓存**

如果  Elasticsearch  没有足够的堆来完成一个操作，它将抛出一个 out-of-memory 的异常，很快该节点就会宕机，并被移出集群。这会给其他的节 点带来额外的负载, 因为系统需要复制和重新分配分配，以恢复到初始配置所需 的状态。由于节点通常是相同的配置，额外的负载很可能使得至少另- 一个节点 耗尽内存，这种多米诺骨牌效应会拖垮整个集群。 当 JVM  堆的资源很紧张的时候，即使在日志中没有看见  out- of-memory  的 异常，节点还是可能变得没有响应。这可能是因为，内存不够迫使垃圾回收器( GC) 运行得更久或者更频繁来释放空闲的内存。由于 GC  消耗了更多的  CPU  资源，节 点花费在服务请求甚至是应答主节点 ping  的计算能力就更少了，最后导致节点 被移出集群。当垃圾回收消耗了过多的  CPU  时间，工程师总是试图发现些神奇的  JVM  设 置来解决所有的麻烦。多数情况下，这不是解决问题的最佳途径，因为过度的垃 圾回收只是 Elasticsearch  需要更多堆内存的征兆。 尽管增加堆的大小是很明显的解决方案，这并非总是可能的。增加数据节点 同样如此。然而，你可以参考些技巧来降低堆的使用。

■减小索引缓冲区的大小。

■减少查询缓存的大小。

■减少搜索和聚集请求中  size  参数的值 ( 对于聚集，还需要考虑到  shard size ) 。

■如果必须处理大规模的数据，你可以增加一些非数据节点和非主节点来扮 演客户端的角色。它们将负责聚合每个分片的搜索结果，以及聚集操作。 最后，Elasticsearch 使用另一种缓存类型来回避  Java  垃圾回收的方式。新的 对象分配到名为新生代的空间。如果新对象存活得足够久，或者太多的新对象分 配到新生代导致其被占满，这些新对象就会被“提升”到老年代。尤其是在聚集 的时候，需要遍历大量的文档并创建很多可能被重用的对象，后一种填满新生代 的情况就会出现。 通常，你希望将这些可能被聚集重用的对象提升到老年代，而不是新生代填 满后恰巧放到老年代的一些随机的、临时的对象。为了实现这个目标， Elasticsearch 实现了一个页面缓存回收器 ( PageCacheRecycler ), 其中被聚集所使 用的大数组被保留下来，不会被垃圾回收。默认的页面缓存是整个堆的 10% ，某 些情况下这个值可能太大( 例如，你有  30 GB  的堆内存，页面缓存就有  3GB  了 ) 。 可以设置elasticsearch.yml 中的 cache . recycler . page. limit . heap 来控该制缓存的 大小。不过，有的时候还是需要调优 JVM 的设置( 尽管默认已经很好了 ), 例如，你的 内存基本够用，但是当一些罕见的长时间 GC  停顿产生的时候，集群还是会遇到 麻烦。有一些设置让垃圾回收发生得更频繁，但是停顿时间更短，降低些整体的 吞吐量来 换取更少的延迟: 增加幸存者区( Survivor ) 的空间 ( 降低 \-XX:SuvivorRatio ) 或者是整个新生代在 堆中的占比( 降低 \-XX:NewRatio ) 。 你可以监控不同的年代来判断这些是否需要。 提升到老年代需要花费更长的等待时间，而更富裕的空间使得新生代的垃圾回收 有较多的时间来清理临时存在的对象: 避免它们被提升到老年代。但是，将新生 代设置得过大，将使得新生代的垃圾回收过于频繁而且变得效率低下，这是因为 生存周期更长的对象需要在两个幸存者空间来回复制。 理想的堆大小: 遵循“一半”原则 在不知道堆的实际使用情况时，经验法则是将节点内存的- 半分配给 Elasticsearch, 但是不要超过  32GB 。这个“一半”法则通常给出了堆大小和系统 缓存之间良好的均衡点。 如果可以监控实际的堆使用情况，一个好的堆大小就是足够容纳常规的使用， 外加可预期的高峰冲击。内存使用的高峰可能会发生。例如，某些人决定在拥有 许多唯一词条的分析字段上，对所有结果运行一次 terms 聚集。这强迫 Elasticsearch 将所有的词条加载到内存中用于统计。如果你不知道会有怎样的高 峰冲击，经验法则同样是一半: 将堆大小设置为比常规高出  50% 。

到此es优化分析完毕，大家要多练习，多思考很快就会得心应手的。