不平衡的 Elasticsearch 性能

Question

我们有一个包含 9 个节点的 Elasticsearch 集群，设置如下：

• Elasticsearch 版本 5.1.2
• 集群中的一个索引
• 主分片存储大小：3GB
• 分片数：5
• 副本数：3
• Node-1、Node-2 和 Node-3 仅限主节点
• Node-4 到 Node-9 仅数据节点
• 映射中没有父子关系
• 每个节点 24 GB 内存，18 核 CPU
• 禁用交换，增加打开文件描述符，12 GB JVM 堆内存
• Nest 客户端“静态”适配器和所有节点 IP 列表

如您所见，我们在节点上过度分配了资源，但在压力测试下，只有一个节点使用了所有可用的搜索线程。正如我所提到的，我们有 18 个内核，根据默认搜索线程限制，我们在每个节点中有 (3*18/2)+1 = 28 个搜索线程。
问题：

• Http 请求不平衡
• 其他节点不使用所有的搜索线程。一个节点使用它的所有线程，它的搜索队列变大了

我们测试过的内容：
- 使用一个协调节点来平衡请求（不变）
我们如何发送请求：
- 我们使用 Elasticsearch 作为搜索引擎，Jmeter 用于对搜索服务进行压力测试。测试服务是使用 Elasticsearch Nest Client 调用 Some SearchTemplates 的 Web 服务

任何想法都值得赞赏。

Answer 1

阅读 https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/connection-pooling.html

看起来你正在使用SingleNodeConnectionPool，当你使用低仪式ElasticClient时使用它，即 var client = new ElasticClient(uri); 在这种情况下，您的所有请求都将发送到一个需要充当Coordinator node 的节点，如下所述：

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html

例如，搜索请求分两个阶段执行，它们是 由接收客户端请求的节点协调 —  协调节点。

在分散阶段，协调节点将请求转发给 保存数据的数据节点。每个数据节点执行 在本地请求并将其结果返回给协调节点。在 收集阶段，协调节点减少每个数据节点的 生成单个全局结果集。

每个节点都隐含地是一个协调节点。这意味着一个节点 将所有三个 node.master、node.data 和 node.ingest 设置为 false 只会充当协调节点，不能被禁用。作为一个 因此，这样的节点需要有足够的内存和 CPU 才能 处理收集阶段。

StaticConnectionPool 或 SniffingConnectionPool 将是您集群的更好选择。