最近公司一个项目es集群连续出现多次打开文件数过多。跟老大讨论并且一起百度翻了翻相关资料。
我们的句柄数已经调到1048576，但是还是一直出现该问题，所以我们考虑es为何会打开如此多文件数。 在这里插入图片描述
下面是搜索的一些信息：
造成打开文件过多的问题的思路并非局限在limit配置。
官网有如下描述：
由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一 个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也 就慢。Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大 的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝 到新的大段中。
由于没有对数据节点做冷热区分，会源源不断的写入到新节点，这就造成了新节点中的段会非常多，旧的段无法合并，新的数据又在源源不断的写入，这就造成了文件数会越来越多，我的情况就是一直有大量新数据源源不断写入，导致旧的段无法合并 解决方法：定期对段进行合并。elk官方建议段的数量是一个分片只有一个。
通过某个进程号显示该进行打开的文件
lsof -p 29624|wc -l
查看某个索引的段数量：
curl 192.168.60.7:9200/_cat/segments/indexName|wc -l
合并某个索引的段：
curl -XPOST 192.168.60.7:9200/indexName/_forcemerge?max_num_segments=1
我的理解：
segments是索引的持久化文件，一个文件叫一个段，es查询的时候会通过内存的id找到对应存储数据的段，打开文件读取记
录。由于我的es源源不断写入，造成文件数越来越多，es无法快速合并成一个大段。在查询时，如果查询的数据对应到多个段， 那么打开的文件数就很多，相反，如果索引合并成一个大段，查询该索引数据的时候，只需打开这个一个文件。所以，解决方 法就是定期对段进行合并。
