正如您在所附屏幕截图中看到的，我们的集群有 11 个节点，但其中一个从节点始终处于红色 CPU 99% 状态。值得一提的是，这从一个奴隶到另一个奴隶的变化。与此同时，最近所有查询响应都非常慢(一个简单的查询可能需要 5 到 8 秒)。我挖掘了数十个有关 Elasticsearch 和 Java 的论坛和资源，但找不到任何解决方案，或者至少找不到有关如何解决此问题的线索。
任何帮助和/或想法将不胜感激。如果需要有关服务器的更多信息，请随时询问，我将提供更新。
谢谢。
最佳答案
如果不深入了解有关索引和正在执行的查询类型的大量详细信息，就很难回答这个问题。我也有过类似的经历，节点较少，但 CPU 始终处于最大状态。以下是我所学到的知识(按重要性排序):
- 将 ES 升级到最新版本(撰写本文时为 1.5)。 1.2 和 1.5 之间存在巨大的性能差异和改进。
- 确保所有节点都运行相同版本的 ES 和 Oracle Java 8。
- 除非您使用特定的
路由，否则查询将命中所有节点，但响应将由一个节点准备。根据正在处理的数据量，这可以解释为什么 CPU 使用率持续较高。 - 确保您的客户端不会每次都连接到同一节点。在 N 个节点上实现轮询以分配查询负载。
- 优化您的查询。使用routing如果可能，请保持索引较小，如果可能的话，创建具有逻辑分割的索引(即/时间戳、用户数据、客户端、类别等)
- 保留fielddata尽可能小并尽可能优化。执行查询所需的字段数据量越大，节点使用的 CPU 就越多，集群的速度就越慢。查看doc_values .
- 您真的需要 11 个节点吗？如果您的查询不使用路由，则您执行的每个查询都会命中每个节点。每个节点依次将其答案发送到处理节点。这意味着处理节点需要做更多的工作，因为它现在必须组合来自 11 个不同节点(而不是 2 个或 3 个节点)的数据。
- 对于 11 个节点，您还可以考虑让一两个节点专门用于处理查询(即它们不存储数据)，其他节点专门用于存储数据。
ElasticSearch 团队在每个版本中都取得了巨大进步...因此，只要有可能，首先要做的就是升级到最新的稳定版本。我从 1.3 升级到 1.5，许多问题都消失了:)
关于java - Elasticsearch 响应时间慢，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24540318/