ES7.17版本terms查询性能问题

简介: ES迭代过程支持了越来越多特性与优化,版本升级显得十分必要。测试又很难覆盖所有场景,灰度升级过程中难免遇到一些问题,这里主要分析terms查询的一个性能损失问题。

背景

1.对于7版本(大版本)集群希望只维护一个版本,最终选择7.17,对同大版本的7.5版本集群进行升级


2.根据官方描述,_id放到堆外性能损失非常小可以忽略,且对BKD进行了优化


3.升级完成,一段时间之后,收到用户报障


1-cpu.png

2-time.png


4.抽样检查了下部分升级的集群,其中部分受到影响,部分不受影响。且每个集群内存均有一定优化(预期内)


调查&分析

1.发现is_deleted文档特别多,怀疑是7.17版本对于碎片过于敏感。做forcemerge,没什么效果。


2.GET _nodes/hot_threads 查看耗时部分,结果展示笼统,没得到关键信息。


3.给语句加上profile,查看耗时部分。

GET index-v1/_search
{"profile":"true","query":{"bool":{"filter":[{"term":{"xid":{"value":"11111111","boost":1.0}}},{"terms":{"status":[2,3,4],"boost":1.0}},{"terms":{"platform":["aaa","bbb"],"boost":1.0}},{"terms":{"pId":[1,2],"boost":1.0}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"time":{"order":"desc"}}]}


从脱敏的简化结果中可以看出来,主要是 status、pId 字段耗时高,这两个字段都是integer类型,并且使用了terms查询。

{
  "took": 554,
  "timed_out": false,
  "_shards": {
    "total": 3,
    "successful": 3,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 5,
      "relation": "eq"
    },
    "max_score": null,
    "hits": [
      ...
    ]
  },
  "profile": {
    "shards": [
      {
        "id": "[APxxxxxxxxxxxxxxQ][index-v1][0]",
        "searches": [
          {
            "query": [
              {
                "type": "BooleanQuery",
                "description": "#xid:111111111 #status:{2 3 4} #ConstantScore(platform:aaa platform:bbb) #pId:{1 2}",
                "time_in_nanos": 415205306,
                "breakdown": {
                  ...
                  "build_scorer": 415028271
                },
                "children": [
                  {
                    "type": "TermQuery",
                    "description": "xid:111111111",
                    "time_in_nanos": 102656,
                    "breakdown": {
                      .....
                      "build_scorer": 86264
                    }
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "status:{2 3 4}",
                    "time_in_nanos": 220394978,
                    "breakdown": {
                      ....
                      "build_scorer": 220385119
                    }
                  },
                  {
                    "type": "ConstantScoreQuery",
                    "description": "ConstantScore(platform:aaa platform:bbb)",
                    "time_in_nanos": 341845,
                    "breakdown": {
                      .....
                      "build_scorer": 282277
                    },
                    "children": [
                      {
                        "type": "BooleanQuery",
                        "description": "platform:aaa platform:bbb",
                        "time_in_nanos": 329042,
                        "breakdown": {
                          .....
                          "build_scorer": 277752
                        },
                        "children": [
                          {
                            "type": "TermQuery",
                            "description": "platform:aaa",
                            "time_in_nanos": 62446,
                            "breakdown": {
                              .....
                              "build_scorer": 37931
                            }
                          },
                          {
                            "type": "TermQuery",
                            "description": "platform:bbb",
                            "time_in_nanos": 15093,
                            "breakdown": {
                              .....
                              "build_scorer": 6981
                            }
                          }
                        ]
                      }
                    ]
                  },
                  {
                    "type": "PointInSetQuery",
                    "description": "pId:{1 2}",
                    "time_in_nanos": 194164297,
                    "breakdown": {
                      ....
                      "build_scorer": 194160452
                    }
                  }
                ]
              }
            ],
            "rewrite_time": 40044,
            "collector": [
              {
                "name": "SimpleFieldCollector",
                "reason": "search_top_hits",
                "time_in_nanos": 144012
              }
            ]
          }
        ]

4.单个的profile无法说明问题,进一步排查:使用arthas工具获取一段时间内的火焰图

3-火焰图.png

可以看到主要就是BKD数据结构占用的CPU。


5.参考官方论坛相似问题:https://discuss.elastic.co/t/very-slow-search-performance-after-upgrade-to-7-16-1/296152/3


6.integer类型的terms查询性能较差,看起来官方描述的BKD相关优化指的是range


7.测试验证,将字段改成keyword,查看结果,CPU查询耗时恢复到正常范围


4-结果.png

5-结果-time.png

相关文章
|
缓存 Java 索引
Elasticsearch的TermsQuery慢查询分析和优化
前言 本篇文章主要记录业务上的一个TermsQuery优化和分析的过程和一些思考。 在使用ES的时候,经常会遇到慢查询,这时候可以利用profile进行分析,当利用profile也查看不出什么端倪时候,可以尝试通过阅读代码查看查询为什么这么慢。如下是一个我们内部业务的一个慢查询,经常出现4s左右的延时,一模一样的查询,但是延时不一样,且很难复现。 { "from": 0,
3862 0
Elasticsearch的TermsQuery慢查询分析和优化
|
监控 Java 索引
ES 生产中10个常见参数阈值(默认最大值)操作及优化解决方案
ES 生产中10个常见参数阈值(默认最大值)操作及优化解决方案
ES 生产中10个常见参数阈值(默认最大值)操作及优化解决方案
|
缓存 索引
ES经典面试题:谈谈filter和query有什么区别?
ES经典面试题:谈谈filter和query有什么区别?
840 0
ES经典面试题:谈谈filter和query有什么区别?
|
存储 JSON 固态存储
【离线】esrally实践总结
1.真正的离线安装esrally 2.术语介绍,官方数据集、track介绍 3.官方数据集下载 4.离线使用esrally测试现有ES测试集群 5.对比两次race(测试)的结果 6.测试时间太长怎么办? 7.报告分析
3895 2
【离线】esrally实践总结
|
网络安全 网络架构 Windows
详解Traceroute过防火墙回显问题,原来如此!
详解Traceroute过防火墙回显问题,原来如此!
664 2
WK
|
并行计算 安全 Java
什么是GIL
全局解释器锁(GIL)是Python中一个重要的特性,它作为一个互斥锁,确保同一时间只有一个线程执行Python字节码,从而简化了内存管理和避免了线程安全问题。GIL的设计初衷是为了简化内存管理并提高某些场景下的性能,但对于CPU密集型任务,它可能成为瓶颈。为解决这一限制,Python程序员可以采用多进程或多线程结合优化等策略。理解GIL的工作原理有助于编写更高效的多线程Python程序。
WK
1474 0
|
监控 固态存储 安全
源码剖析:Elasticsearch 段合并调度及优化手段
源码剖析:Elasticsearch 段合并调度及优化手段
|
弹性计算 Linux 存储
初识LVM及ECS上LVM分区扩容
LVM是逻辑卷管理(Logical Volume Manager)的简称,它是Linux环境下对磁盘分区进行管理的一种机制,LVM是建立在硬盘和分区之上的逻辑层,来提高磁盘分区管理的灵活性。
10309 155
|
存储 缓存 自然语言处理
ES 性能调优,这可能是全网最详细的 Elasticsearch 性能调优指南
ES 性能调优,这可能是全网最详细的 Elasticsearch 性能调优指南
ES 性能调优,这可能是全网最详细的 Elasticsearch 性能调优指南