ES的segment的问题

起因：用户发现ES索引占用文件句柄过高，经过各种排查（（0-0）过程这里不叙述了），结论就是ES的segment过于零散，发现可能是segment没有进行自动合并，所以需要在这一块进行优化

首先，解决问题：

对segment进行手动合并，通过以下命令:

POST  /INDEX/_forcemerge
{
  "max_num_segments":1
}
//该命令针对5.0以上版本的ES，5.0以下可以使用以下
POST  /INDEX/_optimize
{
  "max_num_segments":1
}

以下这篇转载的原创文章里面有专门查看forcemerge相关的信息
elasticsearch force merge 步骤 原创

segment优化

在ES的默认配置中，segment的默认合并大小为2M，就是当segment大小达到2M时，会自动进行segment的合并，可以通过以下命令查看到

GET INDEX/_setting?include_defaults

"policy": {
    "fool_segment": "2mb",
    "max_merge_at_once_explicit": "30", //显示调用optimize 操作或者 expungeDeletes时可以操作多少个segments，默认是30
    "max_merge_at_once": "10",//一次最多只操作多少个segments，默认是10.
    "max_merged_segment": "5gb",//超过多大size的segment不会再做merge，默认是5g
    "expunge_deletes_allowed": "10.0",//指删除了的文档数在一个segment里占的百分比，默认是10，大于这个值时，在执行expungeDeletes 操作时将会merge这些segments.
    "segments_per_tier": "10.0"//每个tier允许的segement 数，注意这个数要大于上面的at_once数，否则这个值会先于最大可操作数到达，就会立刻做merge，这样会造成频繁的访问操作
}

上述这些样式都是可以动态优化的通过以下命令

PUT INDEX/_settings
{
   "merge.policy.fool_segment": "2mb",
    "mergr.policy.max_merge_at_once_explicit": "30", 
    "mergr.policy.max_merge_at_once": "10",
    "mergr.policy.max_merged_segment": "5gb",
    "mergr.policy.expunge_deletes_allowed": "10.0",
    "mergr.policy.segments_per_tier": "10.0"
}

通过上述命令对ES的segment的参数进行动态优化，减轻磁盘IO压力，减少文件句柄数