从400+节点Elasticsearch集群的运维中，我们总结了这些履历

为了节制查询执行进程，我们开拓了一个插件，，实现了一系列自界说查询范例。通过行使这些查询范例来提供 Elasticsearch 官方版本不支持的成果和机能优化。好比，我们实现了 phrases 中的 wildcard 查询，支持在 SpanNear 查询中执行;另一个优化是支持“*”取代 match-all-query;尚有其他一系列特征。

Elasticsearch 和 Lucene 的机能高度依靠于详细的查询和数据，没有银弹。即便云云，仍可给出一些从基本到进阶的参考：

• 限定你的检索范畴，仅涉及相干数据。好比，对付逐日索引库，只按相干日期范畴检索。对付检索范畴中间的索引，停止行使范畴查询 / 过滤器。
• 行使 wildcards 时忽略前缀 wildcards- 除非你能对 term 成立倒排索引。双端 wildcards 难以优化。
• 存眷资源耗损的相干迹象 数据节点的 CPU 占用一连飙高吗?IQ 守候走高吗?看看 GC 统计。这些可以从 profilers 器材可能通过 JMX 署理得到。假如 ParNewGC 耗损了高出 15% 的时刻，去搜查下内存日记。假若有任何的 SerialGC 搁浅，你也许真的碰着题目了。
• 假如碰着垃圾接纳题目，请不要实行调解 GC 配置。 这一点常常产生，由于默认配置已经很公道了。相反，应该聚焦在镌汰内存分派上。详细怎么做?参考下文。
• 假如碰着内存题目，但没偶然刻办理，可思量下 Azul Zing。这是一个很贵的产物，但仅仅行使它们的 JVM 就可以晋升 2 倍的吞吐量。不外最终我们并没有行使它，由于我们无法证明物有所值。
• 思量行使缓存，包罗 Elasticsearch 外缓存和 Lucene 级此外缓存。在 Elasticsearch 1.X 中可以通过行使 filter 来节制缓存。之后的版本中看起来更难一些，但貌似可以实现本身用于缓存的查询范例。我们在将来进级到 2.X 的时辰也许会做相同的事变。
• 查察是否有热门数据(好比某个节点包袱了全部的负载)。可以实行平衡负载，行使分片分派过滤计策 shard allocation filtering，可能实行通过集群从头路由 cluster rerouting 来自行迁徙分片。我们已经行使线性优化自动从头路由，但行使简朴的自动化计策也大有辅佐。
• 搭建测试情形(我更喜好条记本)可从线上情形加载一部门代表性的数据(提议至少有一个分片)。行使线上的查询回放加压(较难)。行使当地配置来测试哀求的资源耗损。
• 综合以上各点，在 Elasticsearch 历程上启用一个 profiler。这是本列表中最重要的一条。我们同时通过 Java Mission Control 和 VisualVM 行使航行记录器。在机能题目上实行谋利(包罗付费参谋 / 技能支持)的人是在挥霍他们(以及你本身)的时刻。排查下 JVM 哪部门耗损了时刻和内存，然后试探下 Elasticsearch/Lucene 源代码，搜查是哪部门代码在执行可能分派内存。
• 一旦搞清晰是哀求的哪一部门导致了相应变慢，你就可以通过实行修改哀求来优化(好比，修改 term 聚合的执行提醒，可能切换查询范例)。修改查询范例可能查询次序，可以有较大影响。假如不奏效，还可以实行优化 ES/Lucene 代码。这看起来太浮夸，却可觉得我们低落 3 到 4 倍的 CPU 耗损和 4 到 8 倍的内存行使。某些修改很渺小(好比 indices query)，但其他人也许要求我们完全重写查询执行。最终的代码严峻依靠于我们的查询模式，以是也许得当也也许不得当他人行使。 - 除非你能对 term 成立倒排索引。双端 wildcards 难以优化。

图表声名：相应时刻。有 / 没有 重写 Lucene 查询执行。同时也表白不再有节点天天产生多次内存不敷的环境。

趁便声名下，由于我知道谋面对一个题目：从上一次机能测试我们知道通过进级到 ES 2.X 能小幅晋升机能，可是并不能改变什么。话虽云云，但假如你已经从 ES 1.X 集群迁徙到了 ES 2.X，我们很愿意听取关于你怎样完成迁徙的实践履历。

假如读到了这里，声名你对 Elasticsearch 是真爱啊(可能至少你是真的必要它)。

英文原文链接：http://underthehood.meltwater.com/blog/2018/02/06/running-a-400+-node-es-cluster/

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!