java - ElasticSearch - 打开的文件太多

Question

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

我在单个 Ubuntu Sever 16.04 节点(12 核，256G ram) 上运行 ElasticSearch 2.4。我已将 ulimit 增加到 > 130k(并通过 _nodes/stats/process 进行验证)。

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

现在，我正在使用多达 900 个并发 Java TransportClient 进行编写，这会导致 ElasticSearch 服务器在几秒钟内崩溃，并抛出“打开文件过多”异常。

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

Answer 1

事实是这样的:

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

我们切换到Jest客户端显着减少了客户端和服务器的负载。现在，900 个并发 Activity 客户端会在服务器上产生 <2000 个文件描述符。

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