ES运维（六）_segment合并使用原理及场景

一、背景简介

ES中，每个index（索引）都包含若干个Shard（分片），每个分片底层又是一个个Segment文件（段），每次数据的读写底层就是与一个个段文件的交互，因此ES调优常用的一块就是对段文件的调优，即对每个分片中段文件数据、大小控制，段合并（Merge）等

二、原理介绍

1、 在ES中，单个倒排索引文件被称为Segment,这个Segment一旦生成就不可变更，多个Segments汇总在一起，就是一个Shards

2、 当有新文档写入并且执行Refresh，就会生成一个新Segment。Shard中有一个文件，用来记录所有Segments信息，叫做Commit Point。查询时会同时查询所有Segments，并且对结果汇总。

3、 删除的文档信息，保存到“.del“文件中，查询后会进行过滤。

4、 Segment会定期Merge，合并成一个，同时真正物理删除已删除文档

三、优化建议

1、 默认情况下ES会开三个并发自动进行Merge操作，但Merge操作相对比较重，需要优化以降低对系统的影响，这里主要考虑两个方面；

A、 降低分段产生的数量/频率

将Refreash Interval调整到分钟级别（根据业务实时性要求来调整）

适当加大Indices.memory.index_buffer_size值（默认时10%），该参数的意思是当buffer超过这个设置值时会自动触发一次flush的操作

尽量避免文档的更新操作

B、 降低最大分段大小，避免较大的分段继续参与Merge，节省资源。（劣势是最终会有多个分段）

Index.merge.policy.segments_per_tier，默认为10，越小需要越多的合并操作

Index.merge.ppolicy.max_merged_segment，默认5GB，超过此大小以后，就不再参与后续的合并操作

2、 Force Merge

A、 当Index不再有写入操作时，可以先将此索引设置成readonly模式，再进行force merge，可以提升查询速度，减少内存开销

B、 关于force merge时设置的文档数，首先也是越少越好，最好可以设置为1，这样操作时会占用大量网络，IO和CPU，因此考虑到业务影响，可以适当增大分段数（Shard的大小/Index.merge.policy.max_merged_segment的大小=最终分段数）。

四、案例分析

1、 某客户es集群，8C32G，4个数据节点，发现业务高峰cpu波动较大，'GET _nodes/hot_threads'命令查看热点线程发现有很多'Lucene Merge Thread'，此时建议可以在数据写入低峰执行：

POST /logs-000001/_forcemerge?max_num_segments=1

2、 某客户ES经常进行update操作，但有些分片的Segment已经接近5G，不再自动刷新，导致很多数据无法物理删除占用大量磁盘空间，此时也可以在业务低峰期做一下此操作，强制合并Segment文件，物理删除已标记删除的文件：

POST /logs-000001/_forcemerge?max_num_segments=1

备注：es相关操作命令：

1、force merge

POST /logs-000001/_forcemerge?max_num_segments=1

2、查看集群索引segment信息

GET _cat/segments?v

3、获取热点线程

GET _nodes/hot_threads?human=true

4、修改索引参数

PUT /index_name/_settings

{

“refresh_interval”: “1s”,

“segments_per_tier”: 15,

“max_merged_segment”: “2G”

}