本文共 1015 字，大约阅读时间需要 3 分钟。

最近公司一个项目es集群连续出现多次打开文件数过多。跟老大讨论并且一起百度翻了翻相关资料。

我们的句柄数已经调到1048576，但是还是一直出现该问题，所以我们考虑es为何会打开如此多文件数。

下面是搜索的一些信息：

造成打开文件过多的问题的思路并非局限在limit配置。

官网有如下描述：

由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就慢。Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。

由于没有对数据节点做冷热区分，会源源不断的写入到新节点，这就造成了新节点中的段会非常多，旧的段无法合并，新的数据又在源源不断的写入，这就造成了文件数会越来越多，我的情况就是一直有大量新数据源源不断写入，导致旧的段无法合并

解决方法：

定期对段进行合并。elk官方建议段的数量是一个分片只有一个。通过某个进程号显示该进行打开的文件

1、lsof -p 29624|wc -l

查看某个索引的段数量：

2、curl 192.168.60.7:9200/_cat/segments/indexName|wc -l

合并某个索引的段：

3、curl -XPOST 192.168.60.7:9200/indexName/_forcemerge?max_num_segments=1

es （修改索引数）arr=`cat /dev/shm/val.txt`for val in $arr ;docurl -XPOST xxx.x.x.x:9200(ip)/$val/_forcemerge?max_num_segments=2done

segments是索引的持久化文件，一个文件叫一个段es查询的时候会通过内存的id找到对应存储数据的段打开文件读取记录。由于我的es源源不断写入，造成文件数越来越多es无法快速合并成一个大段。在查询时，如果查询的数据对应到多个段那么打开的文件数就很多，相反，如果索引合并成一个大段查询该索引数据的时候，只需打开这个一个文件。所以，解决方法就是定期对段进行合并。

转载地址：http://vhqlf.baihongyu.com/