最近公司一个项目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