elasticsearch 段合并实操，带图

  在学习 es 的优化方案，很多文章提到进行段合并，会提升查询的性能。还参考了官网，但是我觉得并不全对。我的数据是8亿，带一个副本，大概是4T。集群是三台机器500G的内存，SSD固态硬盘，三个master节点，六个数据节点，职责分离。堆内存分配的31G；分配的分片数是两百，

 通过在kibana 上执行这个命令: 来进行段合并。

POST  index/_forcemerge?max_num_segments=1

 

  以下的截图：是我在进行段合并的时候，对我的集群状态进行一个截图，包含了GC 的情况，已经IO的情况，以及cpu的负载，最后是段数。（其中官网说 forcemerge 会占用很高的IO和 cpu ）从截图上来看，我的本次merge，IO确实占用了，但是CPU并没有占用很多，而且其中一台占用比较明显

 其中一台的情况：

 另外一台的情况：

 

 

 # # 原理

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。

Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

 

 # # 官网结论

使用optimize优化老的索引，将每一个分片合并为一个单独的段就很有用了；这样既可以节省资源，也可以使搜索更加快速。

但是我在合并后 并没有看到太明显的提升。 这个我再测一下。