ElasticSearch - 打开的文件过多

Question

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

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

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

现在，我正在编写多达900个并发Java TransportClient，导致ElasticSearch服务器在几秒钟内崩溃，导致打开过多的文件＆＃34;异常。

我在这里遗漏了什么吗？对于单个实例来说，900个并发写入是否过多？或者一个节点的10个分片太多了？

Answer 1

事实证明是这样的：

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

我们切换到Jest客户端，这显着减少了客户端和服务器上的负载。 900个并发活动客户端现在在服务器上生成＆l​​t; 2000文件描述符。

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