一个ES index 包含有多个sharding, sharding 主要用于分布式。 一个sharding里面也可以包含多个segment. es 在indexing 的时候会产生很多的segments。 segments 太多会导致文件句柄浪费严重， 并且搜索性能底下。 ES 自己也会去做merge, 算法和cassandra 的sizeTiered 算法类似（但稍逊一些）。合并后，search 性能有所提升，文件句柄所有下降。

如果你想强制进行一次激烈的compact将每个sharding 里面的indexes 数目都变成1.

POST {index-list}/_optimize?max_num_segments=1

然后可以通过

GET {index-list}/_segments 来确认segment count 的数目。

但如果在merge 的时候还有写入，你也有可能发现还有很多segments, 但那些segment 里面的document 会比较少。

在我自己的一次测试中，compact 之前有150 多个segments, compact 后只有5个， 因为有5个sharding. 文件句柄数从2000+ 降到了114 个。

如果要调整es 的默认compact 参数，可以参考

目前我自己遇到的情况是：

我们的某些log 每天产生一个index, 大小在30G左右。有些1个月产生一个log, 大小40~50G. 我们会有一个后台程序，每次产生新的log 后就会对老的index 进行全面的compact.