欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Elasticsearch性能优化建议

程序员文章站 2022-06-07 15:54:46
...

之前公司项目中有使用Elasticsearch存储日志,当时使用的功能简单,并没有深入了解Elasticsearch,但是对于该支持文本搜索的存储架构还是很感兴趣,最近因为想在一个新项目中采用ELKElasticsearch+Logstash+Kibana)技术栈来存储系统日志,学习有关Elasticsearch的书籍(深入理解Elasticsearch,第二版),现在就书本的第八章——提高性能,总结一些有关使用Elasticsearch的Tips,该书采用的elasticsearch为1.4.X版本。

热点线程检测

热点线程API能向你提供系统变慢变卡顿的必需信息,它给出了什么可能是热点的信息,并使你可以看到系统的哪部分需要更深入的分析,例如查询的执行或者Lucene段的合并。热点线程API返回从CPU的角度来看,elasticsearch哪部分的代码可能是热点的信息,或者由于某些原因elasticsearch卡在了哪里。

使用方法

通过使用如下的命令你可以查看所有节点或者某些、某个节点的情况。

/_nodes/hot_threads
/_nodes/{node or nodes}/hot_threads

例如为了查看所有节点上的热点线程,你可以执行如下的命令:
curl 'localhost:9200/_nodes/hot_threads'
此API支持的参数包括

  • threads 需要分析的线程数,默认3
  • interval 前后两次检查的时间间隔
  • type 需要检查的线程状态的类型,默认是CPU,可以是阻塞、等待等线程状态
  • snapshots 需要生产堆栈跟踪快照的数量

例如,想要以1s为周期查看所有节点上处于等待状态的热点线程,可以执行命令:
curl 'localhost:9200/_nodes/hot_threads?type=wait&interval=1s'

执行原理

热点线程检测执行流程如下:

  1. elasticsearch选取所有运行的线程,收集线程花费CPU的各种信息。
  2. 等待interval参数指定的时间后,再次收集步骤1中同样的信息。
  3. 对线程基于其消耗的时间进行排序,取前N(参数threads决定)线程分析
  4. 每隔几毫秒,对3中选择的线程获取一些堆栈的快照,(数量由snapshots参数决定)
  5. 组合堆栈信息,返回响应

返回的响应包括:线程所属节点、消耗CPU时间的百分比、使用CPU的方式、线程名,最后跟着一个堆栈跟踪信息,通过以上信息可以定位节点的性能问题。

高负载场景的分类

高负载场景可以分为三种情况:

  • 专注于高索引负载
  • 专注于高查询负载
  • 高查询索引负载并行

后面按照三个场景进行说明

查询、索引负载均衡场景

因为是查询、索引负载均衡的场景,所以一下建议不只是与索引性能、查询性能有关,而是与它们都有关。

正确的存储

选择正确的存储实现,在运行1.3版本以后时尤其重要。

  • 如果使用64位系统,考虑使用 mmapfs(内存映射)
  • 基于UNIX系统考虑选择 Niofs
  • windows系统应该选择 simplefs
  • 非持久化的存储考虑 内存存储

elasticsearch 1.3版本以后,默认使用的存储类型是一个 混合 的存储类型default,使用内存映射文件读取term字典,doc values,其他文件采用nio存储。

索引刷新频率

索引刷新的频率是指文档需要多长时间才能出现在搜索结果中。规则非常简单:刷新频率越短,查询越慢,且索引文档的吞吐量越低。默认的刷新频率是1s,这意味着索引查询器每1s都会重新打开一次。如果可以接受一个较慢的刷新频率,可以设置成5s、10s、30s等。

线程池调优

但你看到节点正在填充队列并且仍然有计算能力剩余,且这些计算能力可以被指定用于处理等待处理操作。线程池调优包括线程数以及等待队列长度两个方面。

调整合并过程

Lucene段合并取决与你追加多少数据、多久追加一次等因素,对于Lucene分段和合并,需要记住:有多个段的索引执行查询比只有少量段的索引上执行慢。性能测试显示多个段上执行查询比只有一个段的索引要慢大约10%-15%。

  • 如果你希望查询快,就需要更少的段

段合并限流,默认情况下elasticsearch会限制合并的速度在20MB/s,elasticsearch需要限流来避免合并过程中过多的影响搜索。如果使用的是SSD硬盘,那么默认20MB/s是不适合的,通过一下参数设置:

  • indices.store.throttle.max_bytes_per_sec设置端合并限流

高查询频率场景

缓存设置

第一个有助于查询性能的缓存是 过滤器缓存 ,可以使用下面的属性,来控制给定节点上能够被过滤器缓存使用的全部内存数量,默认是10%。
indices.cache.filter.size
第二个缓存是 分片查询缓存 ,她的目的是缓存聚合、提示词结果、命中数等,当你的查询使用了聚合、提示词等,最好启用这个缓存。该缓存的大小可以使用如下参数设置:
indices.cache.query.size

查询的思考

  • 总是考虑到优化查询结构、过滤器使用等
  • 过滤器不影响文档的打分,在计算得分时不被考虑进去

使用路由

如果数据可以使用路由,你应该考虑使用它,可以避免在请求特定数据查询时查询所有的分片。

控制size和shard_size

在处理聚合查询时,合理的设置size、shard_size,size定义了聚合结果返回多少组数据,聚合只会返回前size个结果给客户端;size、shard_size具有相同的意思,只是shard_size其作用是在分片的层次上。

高索引吞吐场景

批量索引

合理的使用批量索引可以显著提高索引的速度,但不要向elasticsearch发送过多的超出其能力的批量索引请求。

doc value 与索引速度的权衡

doc value可以帮助具有 排序、聚合、分组 的操作,但是记录doc value需要在索引时做一些额外的操作,这样会 降低索引速度索引吞吐量 ,所以需要结合具体应用场景,权衡 doc value与索引速度。

控制文档的字段

尽量的保持你存储的字段尽可能的少,你在打多少情况下需要保存的字段是_source,在一些场景下需要判断是否需要存储 _all、_source 等字段。
在禁用_all字段时,设置一个新的默认搜索字段是一个很好的实践,使用如下命令设置:
index.query.default_field:set_your_name

调整事务日志

elasticsearch使用事务日志来获取最新的更新,确保数据的持久化以及优化Lucene索引的写入,默认的事务日志最多保留5000个操作,或者最多占用200MB的空间。两者的参数设置如下:

index.translog.flush_threshold_ops
index.translog.flush_threshold_size

如果需要获取更大的索引吞吐量,愿意付出数据在更长的时间内不能被搜索到,可以调高以上两个默认值。并且在故障发生时,拥有大量事务日志的节点需要更长时间去恢复。

最后

以上是有关elasticsearch使用中的小Tips,后期有时间会继续写一些有关elk技术栈的文章。