在log_doc合并策略中，用户可以更改如下的配置项

merge_factor:与log_byte_size合并策略中的属性一样，请考虑该合并策略中对属性的解释。

min_merge_docs:该属性定义了最小段的最小文档数。如果段的文档数低于该值，但是满足merge_factor属性条件，则段会被合并。属性的默认值为1000,且该属性对减少碎片段很有用。但是，如果属性值设置过高，会增加合并的开销。

max_merge_docs:该属性定义了待合并段的最大文档数。默认情况下没有设置，因此对一个段中允许拥有的最大文档数量没有限制。

calibrate_size_by_deletes:该属性值为Boolean类型，默认值为true，指定了标记删除文档的容量在计算段容量时应该予以考虑。

index.compund_format:该属性值为Boolean类型，指定索引是否应该存储为压缩格式。默认情况下为false。其用法请参考tiered合并策略对此属性的解释。

与前面的合并策略类似，上面提到的属性，都应该加上index.merge.policy前缀。因此，如果我们想设置min_merge_docs属性值，就应该使用index.merge.policy.min_merge_docs属性。 此外，log_doc合并策略支持index.merge.async属性和index.merge.async_interval，用法与tiered合并策略一样。

合并的限速配置

segment 归并的过程，需要先读取 segment，归并计算，再写一遍 segment，最后还要保证刷到磁盘。可以说，这是一个非常消耗磁盘 IO 和 CPU 的任务。所以，ES 提供了一些限速机制，确保这个任务不会过分影响到其他任务。

通过内存控制频率

indices.memory.index_buffer_size : 5%

index.cache.field.max_size: 50000 每个segment中可包含的最大的doc数目

控制合并io速率

Indices.store.throttle.type : merge 调节只在merge阶段有效 none 关闭调节 all 全阶段打开调节

Index.store.throttl.max_bytes_per_sec: 100mb 限制Io操作为每秒100mb

在 5.0 之前，默认值是 20MB。5.0 开始，ES 对此作了大幅度改进，使用了 Lucene 的 CMS(ConcurrentMergeScheduler) 的 auto throttle 机制，不再需要手动配置了。官方文档中都已经删除了相关介绍，不过从源码中还是可以看到，这个值目前的默认设置是 10240 MB。

对于写入量较大，磁盘转速较高，甚至使用 SSD 盘的服务器来说，这个限速是明显过低的。社区广泛的建议是可以适当调大到 100MB或者更高。

归并线程的控制

index.merge.scheduler.max_thread_count 归并线程的数目，ES 也是有所控制的。默认是： Math.min(3, Runtime.getRuntime().availableProcessors() / 2)。即服务器 CPU 核数的一半大于 3 时，启动 3 个归并线程;否则启动跟 CPU 核数的一半相等的线程数。如果你确定自己磁盘性能跟不上，可以降低，免得 IO 情况更加恶化。

强制合并 forcemerge 接口

既然默认的最大 segment 大小是 5GB。那么一个比较庞大的数据索引，就必然会有为数不少的 segment 永远存在，这对文件句柄，内存等资源都是极大的浪费。但是由于归并任务太消耗资源，所以一般不太选择加大 index.merge.policy.max_merged_segment 配置，而是在负载较低的时间段，通过 forcemerge 接口，强制归并 segment。

# curl -XPOST https://127.0.0.1:9200/logstash-2015-06.10/_forcemerge?max_num_segments=1

由于 forcemerge 线程对资源的消耗比普通的归并线程大得多，所以，绝对不建议对还在写入数据的热索引执行这个操作。这个问题对于 Elastic Stack 来说非常好办，一般索引都是按天分割的。

在2.0之前是optimize接口。