ES 集群优化

• ES 负载不合理，热点问题严重。

  • ES 主集群有多个节点，有的节点上部署的 shard 数偏多，有的节点部署的 shard 数很少，会导致某些服务器的负载很高，每到流量高峰期，就容易预警。

• ES 线程池的大小设置得太高，导致 cpu 飙高。

  • 设置 ES 的线程池（threadpool） ，一般将线程数设置为服务器的 cpu 核数，即使 ES 的查询压力很大，需要增加线程数，那最好也不要超过“cpu core * 3 / 2 + 1”。如果设置的线程数过多，会导致 cpu 在多个线程上下文之间频繁来回切换，浪费大量 cpu 资源。

• shard 分配的内存太大，100g，导致查询变慢。

  • ES 的索引要合理分配 shard 数，要控制一个 shard 的内存大小在 50g 以内。如果一个 shard 分配的内存过大，会导致查询变慢，耗时增加，严重拖累性能。

• string 类型的字段设置了双字段，既是 text，又是 keyword，导致存储容量增大了一倍

  • 一般信息的查询不需要关联度打分，直接根据 keyword 查询就行，所以完全可以将 text 字段去掉，这样就能节省很大一部分存储空间，提升性能。

• ES 查询，使用 filter，不使用 query。

  • ​​​​​​​ query 会对搜索结果进行相关度算分，比较耗 cpu，而一般信息的查询是不需要算分的，这部分的性能损耗完全可以避免。

• 节约 ES 算力，

  • ​​​​​​​将 ES 的搜索结果排序放在相关系统的 jvm 内存中进行。

• 增加 routing key。

  •  ES 的查询会将请求分发给所有 shard，等所有shard返回结果后再聚合数据，最后将结果返回给调用方。如果事先已经知道数据分布在哪些 shard 上，就可以减少不必要的请求，提升查询性能。