从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/

（编辑：应用网_丽江站长网）

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