最近，我们的集群出现了极端的性能下降。我们有3个节点，64 GB，4CPU（2个核心），每个节点的索引为250M记录，60GB大。表现几个月都可以接受。
从那以后我们就： 1.添加了第四台服务器，配置相同。 2.将索引拆分为两个索引，使用别名查询它们 3.禁用分页（Windows Server 2012） 4.在一个字段上添加了同义词分析
我们的群集现在可以存活几个小时，然后它基本无用。我必须在每个节点上重新启动弹性以纠正问题。我们尝试将每个节点碰到8个cpus（2个核心），几乎没有增益。
一个问题是，每个QUERY都会占用它所击中的任何节点的100％的cpu。每个查询都在3个以上的字段上进行了分析，自从我们的集群运行良好以来，这些字段没有发生变化。不幸的是，我不确定这是否曾经发生过，但肯定这似乎是一个问题。我们需要每隔几秒就能响应多个请求。当多个请求同时进入时，对于那些特定的响应，性能似乎不会变得更糟。同样，随着时间的推移，性能会慢慢下降; CPU（所有核心）无限期地保持最大化。
我在每个盒子上使用elasticsearch 1.3.4和插件elasticsearch-analysis-phonetic 2.3.0，甚至当我们的表现都不那么糟糕时。
有什么想法吗？
更新
似乎性能问题是由于索引别名造成的。当我将站点指向最终存储大约80％数据的单个索引时，CPU没有受到限制。仍然有几个100％的峰值，但它们要短得多。当我将其指向别名（指向总共两个索引）时，我可以通过快速刷新页面十几次来降低群集：每次查询CPU使用率达到100％并且连续多次卡在那里
弹性搜索别名是否存在已知问题？我是否错误地使用了别名？
更新2：
在日志中找到原因。分页查询是可怕的。这是一个有弹性的已知错误吗？如果我运行一个空查询然后尝试查看最后一页（例如100,000,000），它会将整个群集关闭。那个单一的查询。它通过前1.5M的结果然后退出，同时占用100％的CPU超过一分钟。
更新3： 所以这里的其他东西很奇怪。指向dev上的旧索引（相同大小，没有别名）并尝试重现分页问题;群集不会立即被击中。它在查询后的前20秒内有1％的CPU使用率。在CPU使用率上升之前，查询返回错误。大约2分钟后，CPU使用率达到100％，服务器基本崩溃（因为CPU超额征税，所以无法做其他事情）。在生产索引上，此CPU负载是即时的（它在查询后立即发生）
答案 0 :(得分：0)
如果不检查某些指标，则很难确定响应缓慢或任何其他问题的原因。但是从你提到的数据来看，似乎会发生许多缓存驱逐，从而增加了节点上垃圾收集的数量。频繁的垃圾收集（主要是旧的GC）将消耗大量的CPU。这反过来将开始影响所有集群。
如前所述，只有在添加其他节点后才开始提出问题。这让我感到惊讶。是否有增加流量？。
是否可以包含在群集速度变慢时采用的_stats API的输出。它将提供大量信息，我可以从中获得更好的诊断。还包括查询示例。
我建议您安装bigdesk，以便更轻松地获得群集健康状况的图形视图。