在前两次集群扩容的过程中，总是会出现Too many open files in system问题。对于这个问题，困扰了一段时间。由于elasticsearch在非root用户下运行，开始以为只需要调整limit.conf中的句柄数配置就好。但是在我的句柄数已经调到655350之后，还出现这个问题。我通过检查 lsof 命令发现单个节点的句柄数并不在一个数量级。
Paste_Image.png
如上图所示。
现在证明造成打开文件过多的问题的思路并非局限在limit配置。还需要考虑elasticsearch何时会创建大批量的文件？
仔细查看了elasticsearch文档，发现如下描述：
由于自动刷新流程每秒会创建一个新的段，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段；所以段越多，搜索也就越慢。
Elasticsearch通过在后台进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。
段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档（或被更新文档的旧版本）不会被拷贝到新的大段中。
过程如下图：
Paste_Image.png
琐碎的段会自动合并为一个大段，在新的大段被创建完成并flash之后，旧的段会被删除。
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
如下是段合并的效果：
段监控图
总结：
1.需要对elasticsearch制定冷/热策略，将节点分为存放历史数据的冷节点，和存放实时数据的热节点。
2.需要定时对冷数据进行段合并。
