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