解决elasticsearch “Too many open files in system”问题

在前两次集群扩容的过程中,总是会出现Too many open files in system问题。对于这个问题,困扰了一段时间。由于elasticsearch在非root用户下运行,开始以为只需要调整limit.conf中的句柄数配置就好。但是在我的句柄数已经调到655350之后,还出现这个问题。我通过检查 lsof 命令发现单个节点的句柄数并不在一个数量级。

解决elasticsearch “Too many open files in system”问题_第1张图片
Paste_Image.png

如上图所示。
现在证明造成打开文件过多的问题的思路并非局限在limit配置。还需要考虑elasticsearch何时会创建大批量的文件?
仔细查看了elasticsearch文档,发现如下描述:

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

过程如下图:


解决elasticsearch “Too many open files in system”问题_第2张图片
Paste_Image.png

琐碎的段会自动合并为一个大段,在新的大段被创建完成并flash之后,旧的段会被删除。

解决elasticsearch “Too many open files in system”问题_第3张图片
Paste_Image.png

因此,这就解释了“Too many open files in system”问题出现的原因:
在系统扩容的过程中,会有大量的数据被平衡到新的节点,这样会消耗大量的IO,同时,elk集群中的新数据,由于没有对数据节点做冷热区分,会源源不断的写入到新节点,这就造成了新节点中的段会非常多,旧的段无法合并,新的数据又在源源不断的写入,这就造成了文件数会越来越多,因此出现了上述问题。

要想彻底解决上述问题,只有一个办法,那就是定期对段进行合并。elk官方建议段的数量是一个分片只有一个。
可以通过如下api进行设置:

POST /{indexname}/_forcemerge?max_num_segments=1

还支持通配符:

POST /applog-prod-2016.12.*/_forcemerge?max_num_segments=1

可以通过如下API查看索引的段信息:

GET applog-prod-2016.11.30*/_segments

如下是段合并的效果:


解决elasticsearch “Too many open files in system”问题_第4张图片
段监控图

总结:
1.需要对elasticsearch制定冷/热策略,将节点分为存放历史数据的冷节点,和存放实时数据的热节点。
2.需要定时对冷数据进行段合并。

你可能感兴趣的:(解决elasticsearch “Too many open files in system”问题)