ES-使用profile做性能分析

最新推荐文章于 2024-04-03 11:08:01 发布
最新推荐文章于 2024-04-03 11:08:01 发布
阅读量1.7k 收藏 1
点赞数 1
分类专栏： Elasticsearch 文章标签： elasticsearch Powered by 金山文档
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wu892355227/article/details/129333304
版权

描述

用来查看各个组件执行时间的详细信息，但是注意，这个api不会用来测量网络延迟，请求在队列中的等待时间，以及协调节点合并各个分片响应时所花费的时间。

返回结果说明

总体的返回结构

{
   "profile": {
        "shards": [
           {
              "id": "[2aE02wS1R8q_QFnYu6vDVQ][my-index-000001][0]",   (1)
              "searches": [
                 {
                    "query": [...],                                   (2)
                    "rewrite_time": 51443,                                                  (3)
                    "collector": [...]                                                      (4)
                 }
              ],
              "aggregations": [...],                                                        (5)
              "fetch": {...}                                                                (6)
           }
        ]
     }
}

(1) 当前参与响应的分片，id是唯一的，格式是由 节点名 + 索引名 + 分片 组成

(2) query部分的耗时和其他的debug信息

(3) 累计重写的时间

(4) 每个收集器的名称和调用时间

(5) 聚合部分的消耗时间，调用次数，debug信息

(6) fetch部分的耗时和debug信息

注意：可以通过添加参数 ?human=true 使结果可读，默认的时间都是纳秒。比如像这样

query部分

"query": [
    {
       "type": "BooleanQuery",
       "description": "message:get message:search",
       "time_in_nanos": "11972972",
       "breakdown": {...},               
       "children": [
          {
             "type": "TermQuery",
             "description": "message:get",
             "time_in_nanos": "3801935",
             "breakdown": {...}
          },
          {
             "type": "TermQuery",
             "description": "message:search",
             "time_in_nanos": "205654",
             "breakdown": {...}
          }
       ]
    }
]

分析：从query的返回结构来看，这个查询被转换成了Lucene底层的带有两个termQuery的BooleanQuery。type是Lucene底层匹配到的类名，它和elasticsearch的别名是对应的。description描述的Lucene的解析文本，用来区分查询的各个部分。time_in_nanos 是BooleanQuery查询的总耗时，这里约为11毫秒，包含两个子查询的。breakdown部分给出的是更详细的时间花费信息。

breakdown

breakdown包含的信息如下

"breakdown": {
  "set_min_competitive_score_count": 0,
  "match_count": 5,
  "shallow_advance_count": 0,
  "set_min_competitive_score": 0,
  "next_doc": 39022,
  "match": 4456,
  "next_doc_count": 5,
  "score_count": 5,
  "compute_max_score_count": 0,
  "compute_max_score": 0,
  "advance": 84525,
  "advance_count": 1,
  "score": 37779,
  "build_scorer_count": 2,
  "create_weight": 4694895,
  "shallow_advance": 0,
  "create_weight_count": 1,
  "build_scorer": 7112295
}

字段信息：

create_weight：生成查询权重所消耗的时间，lucene要求为每个查询要生成一个weight对象，这个用来保存查询相关联的一些上下文信息。

build_scorer：生成打分器消耗的时间，打分器是为每个文档的匹配程度打分的机制。如果有启用缓存机制，那也可能包含连带的缓存时间。

next_doc：确定那个文档是下一个匹配文档所需要的时间

advance：advance 是低版本的next_doc，区别是需要额外的查询来确定匹配的下一个文档，比如识别，移动跳过 之前的文档等。

match：某些查询，采用的是两阶段来确定匹配的文档。比如说短语查询，首先会先粗略的检查文档的存在，之后再此基础上会进行第二次更加细致的检查，像检查短语的顺序，距离等。这个记录的就是这种查询的消耗。如果没有这样两阶段的查询，那这个值就是0。

score：打分器打分所消耗的时间。

*_count：记录的是调用对应方法的次数，比如next_doc_count，意思是调用nextDoc()这个方法的次数，它的作用是用来帮助判断lucene是怎么选择查询的。

collectors

collector记录的是一些高级执行的详细信息，返回的结构是这个样子

"collector" : [
              {
                "name" : "CancellableCollector",
                "reason" : "search_cancelled",
                "time" : "54micros",
                "time_in_nanos" : 54091,
                "children" : [
                  {
                    "name" : "SimpleTopScoreDocCollector",
                    "reason" : "search_top_hits",
                    "time" : "28.8micros",
                    "time_in_nanos" : 28880
                  }
                ]
              }
            ]

这里看到了一个CancellableCollector包裹了一个SimpleTopScoreDocCollector，SimpleTopScoreDocCollector的作用默认是用来打分和排序的。reason是针对这个类的英文描述，time_in_nanos是总消耗的时间。要注意的是collector的时间是独立的，是单独于query的。下面是各个reason的说明

search_sorted：为文档打分和排序的收集器，这是最常见的。

search_count：只统计匹配文档数量的收集器，不会去拉取文档的数据，当size=0的时候会看到它。

search_terminated_after_count：在匹配到n个文档后停止搜索的收集器，在查询是指定terminated_after_count（实际测试没有发现这个参数的使用场景）参数后可以看到它。

search_min_score：仅返回得分大于n的收集器，在设置参数min_score是可以看到。

search_muilt：一个收集器包含了多个收集器，在一个查询中包含了，搜索，聚合，全局的聚合，post_filter 的时候会出现这种情况。

search_timeout：指定超时后停止执行的收集器，在设置timeout后会看到它。

aggregation：用来收集聚合部分文档的收集器，在name上看到的会是一个聚合的列表，就像这样

global_aggregation：针对全局查询范围聚合的收集器。

rewrite

rewrite指的是lucene查询或者子查询被优化改变的过程，比如BoolQuery->BoolQuery->TermQuery会被优化为TermQuery。rewrite_time记录的是总的rewrite时间。

注意：对于MultiTermQuery 类的查询，这类查询通常包括通配符查询，模糊查询，正则查询等。这一类的查询有与lucene的运行机制，通常不会返给你一个结构化的结果，这种如果不好分析，直接关注总的消耗时间就是了。

aggregation部分

返回的结构

{
  "profile": {
    "shards": [
      {
        "aggregations": [
          {
            "type": "NumericTermsAggregator",
            "description": "my_scoped_agg",
            "time_in_nanos": 79294,
            "breakdown": {
              "reduce": 0,
              "build_aggregation": 30885,
              "build_aggregation_count": 1,
              "initialize": 2623,
              "initialize_count": 1,
              "reduce_count": 0,
              "collect": 45786,
              "collect_count": 4,
              "build_leaf_collector": 18211,
              "build_leaf_collector_count": 1,
              "post_collection": 929,
              "post_collection_count": 1
            },
            "debug": {
              "total_buckets": 1,
              "result_strategy": "long_terms",
              "built_buckets": 1
            }
          },
          {
            "type": "GlobalAggregator",
            "description": "my_global_agg",
            "time_in_nanos": 104325,
            "breakdown": {
              "reduce": 0,
              "build_aggregation": 22470,
              "build_aggregation_count": 1,
              "initialize": 12454,
              "initialize_count": 1,
              "reduce_count": 0,
              "collect": 69401,
              "collect_count": 4,
              "build_leaf_collector": 8150,
              "build_leaf_collector_count": 1,
              "post_collection": 1584,
              "post_collection_count": 1
            },
            "debug": {
              "built_buckets": 1
            },
            "children": [
              {
                "type": "NumericTermsAggregator",
                "description": "my_level_agg",
                "time_in_nanos": 76876,
                "breakdown": {
                  "reduce": 0,
                  "build_aggregation": 13824,
                  "build_aggregation_count": 1,
                  "initialize": 1441,
                  "initialize_count": 1,
                  "reduce_count": 0,
                  "collect": 61611,
                  "collect_count": 4,
                  "build_leaf_collector": 5564,
                  "build_leaf_collector_count": 1,
                  "post_collection": 471,
                  "post_collection_count": 1
                },
                "debug": {
                  "total_buckets": 1,
                  "result_strategy": "long_terms",
                  "built_buckets": 1
                }
              }
            ]
          }
        ]
      }
    ]
  }
}

这里的type，description，time_in_nanos，breakdown同query部分的作用是一样的，这里不做赘述。不同的是返回了一个debug的信息，这个主要描述的是聚合底层的一些特性。

breakdown
"breakdown": {
  "reduce": 0,
  "build_aggregation": 30885,
  "build_aggregation_count": 1,
  "initialize": 2623,
  "initialize_count": 1,
  "reduce_count": 0,
  "collect": 45786,
  "collect_count": 4,
  "build_leaf_collector": 18211,
  "build_leaf_collector_count": 1
}

这里也是一样的，如build_leaf_collector 表示的是调用底层方法getLeafCollector()消耗的时间，需要注意的是reduce当前是保留的，它总是会返回0。

fetch部分

当一个查询需要召回文档的时候，它就会有fetch的部分，像这样：

GET /my-index-000001/_search?filter_path=profile.shards.fetch
{
  "profile": true,
  "query": {
    "term": {
      "user.id": {
        "value": "elkbee"
      }
    }
  }
}

返回的结构会是这个样子：

{
  "profile": {
    "shards": [
      {
        "fetch": {
          "type": "fetch",
          "description": "",
          "time_in_nanos": 660555,
          "breakdown": {
            "next_reader": 7292,
            "next_reader_count": 1,
            "load_stored_fields": 299325,
            "load_stored_fields_count": 5,
            "load_source": 3863,
            "load_source_count": 5
          },
          "debug": {
            "stored_fields": ["_id", "_routing", "_source"]
          },
          "children": [
            {
              "type": "FetchSourcePhase",
              "description": "",
              "time_in_nanos": 20443,
              "breakdown": {
                "next_reader": 745,
                "next_reader_count": 1,
                "process": 19698,
                "process_count": 5
              },
              "debug": {
                "fast_path": 4
              }
            }
          ]
        }
      }
    ]
  }
}

这里time_in_nanos表示的总的消耗时间，next_reader 作用可以对比next_doc，load_source表示加载source的时间，load_stored_fields 表示加载存储字段的时间。debug列出的是杂项的非计时信息。

使用的局限性

  1. profile开销比较大，不能用于生产。

  1. 网络开销它没有办法分析到。

  1. 在队列中的花费，协调节点上的合并开销没有办法分析到。

  1. suggestions, highlighting, dfs_query_then_fetch 这类的api分析不到

  1. 聚合中的reduce部分当前是没有用的。

  1. 返回的结构内容可能会随着版本的变化而变化。

wu892355227
关注
  • 1
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【Elasticsearch】ES查询慢问题排查思路 profile 参数
九师兄
02-23 8153
1.概述 转载：添加链接描述 2.场景 场景1 内存参数配置不合理，文件系统缓存不足。 场景2 查询范围过大，一次查询过多的分片，如全表扫描查询。 场景3 进行深度翻页查询，如查询10000之后的结果。 场景4 查询返回的结果集过大，如10w。 场景5 查询语句不是最优，如过滤查询可以使用filter。 场景6 使用模糊匹配查询造成内存溢出的问题。 场景7 聚合查询返回的结果集过大，聚合的范围过大。 场景8 聚合查询多唯一值引起的高内存使用率。 场景9 用text字段进行排序，造成fiel
【Elasticsearch】ES 慢查询 profile 参数
九师兄
05-18 1603
1.概述 es profile 参数类似逆向解析dsl，排查查询慢在哪？ 打印出DSL，可以通过接口： searchSourceBuilder.toString() 新增profile参数，查看到底哪里慢了。profile API的目的是：将ES高层的ES请求拉平展开，直观的让你看到请求做了什么，每个细分点花了多少时间。给你改善性能提供相关支撑工作。 使用举例如下： GET /_search { "profile": true, "query" : { "match" : { "me.
Elasticsearch查询——Profile API（性能分析）
大风的博客
12-22 1万+
Profile API 性能分析 平时开发的过程中我们可能需要对一些查询操作进行优化，而优化之前的工作就是要对操作的性能进行分析，而ES提供了Profile API来帮助用户进行性能分析。它让用户了解如何在较低的级别执行搜索请求，这样用户就可以理解为什么某些请求比较慢，并采取措施改进它们。 需要注意的是Profile API不测量网络延迟、搜索资源获取阶段、请求在队列中花费的时间或在协调节点上合并...
ElasticSearch中profile API的使用
不见其长，日有所长
03-29 5972
1. 前言 profile API 是 Elasticsearch 5.x 的一个新接口。通过这个功能，可以看到一个搜索聚合请求，是如何拆分成底层的 Lucene 请求，并且显示每部分的耗时情况。 2. profile API 使用 可以通过在 query 部分上方提供 “profile: true” 来启用Profile API。 GET /ljjtest/book/_search { "p...
ES查询优化之Profile API
zhinengyunwei的博客
01-14 2548
作者： 石文 时间：2019-04-01 Profile API 用于定位查询过程中的异常耗时问题的。具体使用方法参考如下链接：https://www.elastic.co/guide/en/elasticsearch/reference/5.2/search-profile.html 使用Profile API功能对查询进行耗时定位，返回结果格式如下： { "took":4, #查...
Elasticsearch大文件检索性能提升20倍实践（干货）
热门推荐
铭毅天下Elasticsearch
09-18 2万+
少废话，直接开始。1、大文件是多大？ES建立索引完成全文检索的前提是将待检索的信息导入Elaticsearch。项目中，有时候需要将一些扫描件、PDF文档、Word、Excel、PPT等文档内容导入Elasticsearch。比如：将《深入理解Elasticsearch》这边书导入ES，而这边书的全文内容被识别后的大小可能为3MB——5MB以上的字节。存入ES后是一个content字段，对这个con
最新版linux elasticsearch-7.13.4-linux-x86_64.tar.gz
07-21
5. 设置环境变量：在`~/.bashrc`或`~/.bash_profile`中添加`export PATH=$PATH:/usr/local/elasticsearch/elasticsearch-7.13.4/bin` 6. 使环境变量生效：`source ~/.bashrc` 7. 由于Elasticsearch需要运行在Java...
最新版linux elasticsearch-7.9.2-linux-x86_64.tar.gz
09-27
Elasticsearch是一个开源的全文搜索引擎，它基于Lucene构建，被广泛应用于数据分析、日志收集、实时搜索等领域。在Linux环境中部署和使用Elasticsearch 7.9.2是许多IT专业人士的重要任务。这个版本提供了许多性能...
elasticsearch-6.1.2.tar.gz,elasticsearch-5.5.2.tar和head插件
01-31
Elasticsearch是一个强大的开源搜索引擎和分析引擎，常用于大数据处理、日志分析和实时数据分析等领域。在本场景中，我们有两个版本的Elasticsearch：6.1.2和5.5.2，以及一个名为"head"的插件。本文将详细介绍如何在...
elasticsearch-7.14.0.zip
10-06
Elasticsearch是一个开源的全文搜索引擎，广泛应用于大数据分析、日志收集、实时搜索等领域。它基于Lucene库，提供了一种分布式、RESTful风格的搜索和数据分析能力。在Linux操作系统上安装和配置Elasticsearch是许多...
elasticsearch-6.5 Linux版本，亲测可用.zip
03-08
Elasticsearch是一个开源的全文搜索引擎，广泛应用于大数据分析、日志收集、实时搜索等领域。6.5版本是其历史上的一个重要版本，具有诸多特性和改进。以下是对Elasticsearch 6.5在Linux环境下安装、配置及使用的一些...
基于Lucene查询原理分析Elasticsearch的性能
xuciyisheng的博客
10-30 777
前言 Elasticsearch是一个很火的分布式搜索系统，提供了非常强大而且易用的查询和分析能力，包括全文索引、模糊查询、多条件组合查询、地理位置查询等等，而且具有一定的分析聚合能力。因为其查询场景非常丰富，所以如果泛泛的分析其查询性能是一个非常复杂的事情，而且除了场景之外，还有很多影响因素，包括机型、参数配置、集群规模等等。本文主要是针对几种主要的查询场景，从查询原理的角度分析这个场景下的查...
ES 性能调优过程
u010483897的博客
04-14 930
背景：在数据和服务都准备完成的情况下，打开页面，发现请求需要要几秒才返回； 思路：1.查看搜索接口请求本身耗时情况，排除网络抖动因素，发现搜索接口请求到ES返回结果本身耗时较高； 2.检查每次请求到ES的入参，并在原有参数中加入"profile":true，查看ES处理搜索请求的耗时分布情况； 入参： 返回： 发现只是一个简单的termQuery耗时818ms，然后查看是否ES集群负载情...
Elasticsearch的TermsQuery慢查询分析和优化
hellozhxy的博客
08-02 1758
本篇文章主要记录业务上的一个TermsQuery优化和分析的过程和一些思考。在使用ES的时候，经常会遇到慢查询，这时候可以利用profile进行分析，当利用profile也查看不出什么端倪时候，可以尝试通过阅读代码查看查询为什么这么慢。如下是一个我们内部业务的一个慢查询，经常出现4s左右的延时，一模一样的查询，但是延时不一样，且很难复现。
为什么Elasticsearch查询变得这么慢了？
hellozhxy的博客
08-02 1232
让index压力分摊至多个节点：可通过index.routing.allocation.totalshardsper_node参数，强制限定一个节点上该index的shard数量，让shard尽量分配到不同节点上 综合考虑整个index的shard数量，如果shard数量（不包括副本）超过50个，就很可能引发拒绝率上升的问题，此时可考虑把该index拆分为多个独立的index，分摊数据量，同时配合routing使用，降低每个查询需要访问的shard数量。通常，当您使用搜索引擎时，您需要最准确的结果。
ElasticSearch 实战：查询Profile API（性能分析）
最新发布
qq_33240556的博客
04-03 590
使用Elasticsearch的Profile API可以深入剖析查询执行的各个环节，识别性能瓶颈并针对性地进行优化。通过观察查询耗时、查询阶段、细分耗时和结果收集等关键指标，结合具体的查询语句和索引结构，可以制定出有效的优化策略，提升查询性能。在持续优化过程中，反复使用Profile API进行对比分析，以验证优化措施的效果。结合Elasticsearch的其他监控工具和配置调整手段，可以构建出高效、稳定的搜索服务。
用PROFILE API 定位 ES 慢查询
u010325193的博客
12-06 2102
转载处：https://www.easyice.cn/archives/267 有时在发起一个查询时，他会被延迟，或者响应时间很慢，查询缓慢可能会有多种原因；范围包括 shard 问题，或者计算查询中的某些元素。 从 elasticsearch 2.2版本开始提供 Profile API 供用户检查查询执行时间和其他详细信息。在这篇博客中，我们将探讨如何使用profile API查看查询计时。 ...
ES 查询二，基于DSL的查询（Request Body查询）
问道至简
11-21 491
ES 查询，基于DSL 的查询
Elasticsearch：高级调优 - 查找和修复慢速 Elasticsearch 查询
Elastic 中国社区官方博客
11-30 2723
Elasticsearch 是一个非常灵活且功能丰富的应用程序，它提供了许多不同的方式来查询你的数据。 但是你是否曾经遇到过低于你希望的查询速度？ 对于像 Elasticsearch 这样的分布式系统，可能有各种影响查询性能的因素，包括外部因素，例如负载均衡器设置、网络延迟（带宽、NIC 卡/驱动程序）等。 在本博客中，我将讨论导致查询缓慢的原因以及如何在 Elasticsearch 的上下文中识别它们。 本文源于我们一些常见的故障排除方法，这些方法可能需要人们对 Elasticsearch 的工作原理相
如何使用 es7.1.1 elasticsearch-sql
07-28
要使用 Elasticsearch SQL 插件，您需要先确保您已经安装了 Elasticsearch 7.1.1 版本。然后，按照以下步骤进行操作： 1. 安装 Elasticsearch SQL 插件： - 打开终端或命令提示符窗口。 - 运行以下命令安装 Elasticsearch SQL 插件： ``` ./bin/elasticsearch-plugin install https://github.com/NLPchina/elasticsearch-sql/releases/download/7.1.1.0/elasticsearch-sql-7.1.1.0.zip ``` - 安装完成后，重启 Elasticsearch 以使插件生效。 2. 使用 Elasticsearch SQL： - 打开终端或命令提示符窗口。 - 进入 Elasticsearch 的安装目录。 - 运行以下命令以启动 Elasticsearch SQL 查询： ``` ./bin/elasticsearch-sql-cli ``` - 您将进入 Elasticsearch SQL 的命令行界面。 - 现在，您可以开始使用 SQL 语法来查询 Elasticsearch 数据。 例如，您可以运行以下命令来执行一个简单的 SELECT 查询： ``` SELECT * FROM your_index_name WHERE your_field_name = 'your_value' ``` 注意：在上述查询中，`your_index_name` 是您要查询的索引名称，`your_field_name` 是您要查询的字段名称，`your_value` 是您要匹配的字段值。 这样，您就可以使用 Elasticsearch SQL 插件来执行 SQL 查询并检索 Elasticsearch 中的数据了。请记住，Elasticsearch SQL 插件提供了一种方便的方式来使用 SQL 语法进行查询，但它可能不适用于所有类型的查询，特别是复杂的查询。因此，在使用插件时，请确保您了解其使用限制和适用场景。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值