ElasticSearch - 打开的文件太多答案

【问题标题】：ElasticSearch - Too many open filesElasticSearch - 打开的文件太多
【发布时间】：2017-03-03 15:36:08
【问题描述】：

我知道这是一个已知和讨论过的问题，但我只想在这里获得尺寸：

我在单个 Ubuntu Sever 16.04 node (12 cores, 256G ram) 上运行 ElasticSearch 2.4。我增加了ulimit to > 130k（并通过_nodes/stats/process 验证）。

我有两个索引，每个索引有 10 个分片（因为很快会有多个节点加入集群）。

现在我正在编写多达 900 个并发 Java TransportClients，这会导致 ElasticSearch 服务器在几秒钟内崩溃，引发“打开的文件过多”异常。

我在这里遗漏了什么吗？单个实例处理 900 次并发写入是否太多？还是 10 个分片对于一个节点来说太多了？

【问题讨论】：

这个节点总共有多少个segment文件？您的 900 个并发 Java 客户端与 ES 节点位于同一台机器上？
查询段数的查询：GET /_nodes/stats/indices?filter_path=**.segments.count
而 'max_file_descriptors' 值确实反映了您在操作系统中设置的内容？
远程客户端如何访问这个集群？对每个打开多少个网络连接感兴趣......这些确实计入文件描述符限制。例如，如果来自单个客户端的每个请求都是一个忘记关闭它的新连接，那么您可能会遇到问题。
嗯...那一定是打开了网络套接字？...我不明白为什么 ES 本身会为每个客户端访问打开约 1000 个文件描述符。

【解决方案1】：

事实证明是这样的：

通过 Java TransportClient 进行连接会产生巨大的开销。它不使用 HTTP REST API，而是使用 ES 二进制协议。（如解释here）
- 通过 TransportClient 的查询比通过 REST 的速度快得可以忽略不计。
- TransportClient 在客户端上创建一个线程池，目前该线程池是不可配置的。它将维护多个连接，以便节点能够应对故障转移检索集群统计信息等。这会导致客户端长期承受相当大的负载。
- 在我们的例子中，每个额外连接的 TransportClient 都会在 ES 机器上生成大约 1000 个打开的文件描述符。

我们切换到Jest 客户端，显着降低了客户端和服务器的负载。 900 个并发活动的客户端现在会在服务器上产生

感谢Andrei Stefan 为我们指明了正确的方向。

【讨论】：