java - ElasticSearch-打开的文件太多

我知道这是一个已知且已讨论的问题，但我只想在此处获取尺寸:

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

我有两个带有10个分片的索引(因为多个节点很快就会加入集群)。

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

我在这里想念什么吗？ 900个并发写入对于单个实例来说太多了吗？还是一个节点的10个分片过多？

最佳答案

事实证明是这样的:

通过Java TransportClient连接会产生巨大的开销。它不使用HTTP REST API，而是使用ES二进制协议(protocol)。 (如here所述)

通过TransportClient进行的查询比通过REST进行的查询要快得多。

TransportClient在客户端上创建一个线程池，到目前为止该线程池是不可配置的。它将维护多个连接，以便节点能够应付故障转移，检索群集统计信息等。这会导致客户端承受相当大的长期负担。

在我们的情况下，每个附加的已连接TransportClient都会在ES机器上产生约1000个打开文件描述符。

我们切换到Jest客户端，这大大减少了客户端和服务器上的负载。现在，有900个并发 Activity 的客户端在服务器上导致
感谢Andrei Stefan为我们指明了正确的方向。