之前公司项目中有使用Elasticsearch存储日志，当时使用的功能简单，并没有深入了解Elasticsearch，但是对于该支持文本搜索的存储架构还是很感兴趣，最近因为想在一个新项目中采用ELK（Elasticsearch+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技术栈的文章。