Loading [MathJax]/jax/input/TeX/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >如何解读Elasticsearch benchmark上的各种指标

如何解读Elasticsearch benchmark上的各种指标

原创
作者头像
点火三周
修改于 2022-03-17 13:32:00
修改于 2022-03-17 13:32:00
2.1K0
举报
文章被收录于专栏:Elastic Stack专栏Elastic Stack专栏

Elasticsearch 压测工具和基准数据

Elastic针对Elasticsearch性能测试/压力测试提供了一套工具——EsRally,可以方便我们快速的对Elasticsearch按照特定数据、脚本和配置进行相关性能和压力测试,并且返回整个运行过程的详细的运行指标。同时,官方也维护了一套每夜运行的基础测试环境——Elasticsearch-Benchmark,通过提供标准硬件上的测试结果以供大家参考。相信有不少人在正式搭建集群投入生产之前都曾查看过该数据,用于辅助根据和吞吐和性能确定集群规模。

Elasticsearch-Benchmark

以下是Elasticsearch-Benchmark上用于测试的数据集、ES发行分支、运行环境的基本信息

测试的数据集

在这里插入图片描述
在这里插入图片描述

ES发行分支

在这里插入图片描述
在这里插入图片描述

ES发行版本

在这里插入图片描述
在这里插入图片描述

运行环境

Benchmarking Environment:

Current environment

All benchmarks are run on bare-metal machines with the following specifications:

  • CPU: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
  • RAM: 32 GB
  • SSD: Micron_1100_MTFDDAK512TBN
  • OS for Rally load driver servers: - Linux kernel version 4.15.0-76
  • OS for Elasticsearch target servers: - Linux kernel version 4.13.0-45 - /sys/kernel/mm/transparent_hugepage/enabled = always - /sys/kernel/mm/transparent_hugepage/defrag = always - /sys/devices/system/cpu/intel_pstate/no_turbo = 1
  • JVM: JDK bundled with Elasticsearch.

参考意义

虽然说以上的数据并不能直接作为生产集群搭建的依据,但是在通常情况下还是可以作为一个基线参考,以确定特定版本,特定分支,在通常情况下的一个正常吞吐和查询的性能情况。特别是在我们考虑搭建新集群或者升级的时候,作为重要的性能参考指标。比如:

  • 我们是否担忧安全功能全开会影响集群的性能?
  • 我做集群升级是否能够在集群性能上获得更多的提升?
  • docker环境和虚机环境相比性能如何?

要回答这些问题,我们就要参考具体的运行指标了,以 http-logs 为例,benchmark上可以参考如下指标:

  • index-troughput 集群写吞吐 - 3nodes-4g - defaults - 4g - no-src-4g - sorted-4g - no-src-4g-grok - security-4g
  • 4g-io,磁盘io SSD Micron_1100_MTFDDAK512TBN
  • 4g-gc
  • 4g-segment-memory
  • 4g-default-latency
  • 4g-range-latency
  • 4g-hourly_agg-latency
  • 4g-scroll-latency
  • 4g-desc_sort_timestamp-latency
  • 4g-asc_sort_timestamp-latency
在这里插入图片描述
在这里插入图片描述

指标解读

大家一定很纳闷,这里的参数到底是啥意思啊?

这里为大家带来解读,首先是index-troughput,这个指标包含了集群的性能和单机性能两个部分,所以会有更多的指标值:

代码语言:txt
AI代码解释
复制
- 3nodes-4g
- defaults
- 4g
- no-src-4g
- sorted-4g
- no-src-4g-grok
- security-4g

3nodes 自然代表了这是一个三个节点的,4g代表的是这个car是一个4g的堆内存

代码语言:json
AI代码解释
复制
                "track-params": {
                  "number_of_replicas": 1
                },
                "car": "4gheap",
                "node-count": 3
              }

这里,集群模式下是一副本的配置,所以你会看到3节点的吞吐是20000/s左右,而单节点是13000/s左右,主要是副本的原因

如何配置car可以查看EsRally的文档:

在这里插入图片描述
在这里插入图片描述

这里,我们可以看到defaults是一个默认启动的1GB内存的ES节点。

那么剩下的又代表什么呢?

  • no-src-4g —— "source_enabled": false
  • sorted-4g —— 默认排序,只append数据
  • no-src-4g-grok —— "source_enabled": false; "ingest_pipeline": "grok"
  • security-4g —— "x-pack": "security"
代码语言:json
AI代码解释
复制
              {
                "name": "http_logs-no-src-1node",
                "label": "no-src-4g",
                "charts": [
                  "indexing"
                ],
                "challenge": "append-no-conflicts-index-only",
                "track-params": {
                  "source_enabled": false
                },
                "car": "4gheap"
              },
              {
                "name": "http_logs-appendsorted-4g-1node",
                "label": "sorted-4g",
                "charts": [
                  "indexing"
                ],
                "challenge": "append-sorted-no-conflicts",
                "car": "4gheap"
              },
              {
                "name": "http_logs-grok-no-src-1node",
                "label": "no-src-4g-grok",
                "charts": [
                  "indexing"
                ],
                "challenge": "append-index-only-with-ingest-pipeline",
                "track-params": {
                  "source_enabled": false,
                  "ingest_pipeline": "grok"
                },
                "car": "4gheap"
              },
             {
                "name": "http_logs-append-4g-1node",
                "label": "security-4g",
                "charts": [
                  "indexing",
                  "query"
                ],
                "challenge": "append-no-conflicts",
                "car": "4gheap",
                "x-pack": [
                  "security"
                ],
                "exclude-tasks": "force-merge-1-seg,refresh-after-force-merge-1-seg,desc-sort-timestamp-after-force-merge-1-seg,asc-sort-timestamp-after-force-merge-1-seg"
              }
           

我们可以看到这里有挺多的challenge,还是以http_logs为例,我们可以在rally的安装目录下找到tracks/default/http_logs/challenges/default.json,它定义的是基准的测试方案,在运行一次测试的时候我们该执行哪些操作:

代码语言:json
AI代码解释
复制
    {
      "name": "append-no-conflicts",
      "description": "Indexes the whole document corpus using Elasticsearch default settings. We only adjust the number of replicas as we benchmark a single node cluster and Rally will only start the benchmark if the cluster turns green. Document ids are unique so all index operations are append only. After that a couple of queries are run.",
      "default": true,
      "schedule": [
        {
          "operation": "delete-index"
        },
        {
          "operation": {
            "operation-type": "create-index",
            "settings": {{index_settings | default({}) | tojson}}
          }
        },
        {
          "name": "check-cluster-health",
          "operation": {
            "operation-type": "cluster-health",
            "index": "logs-*",
            "request-params": {
              "wait_for_status": "{{cluster_health | default('green')}}",
              "wait_for_no_relocating_shards": "true"
            }
          }
        },
        {
          "operation": "index-append",
          "warmup-time-period": 240,
          "clients": {{bulk_indexing_clients | default(8)}}
        },
        {
          "name": "refresh-after-index",
          "operation": "refresh"
        },
        {
          "operation": {
            "operation-type": "force-merge",
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        },
        {
          "operation": "default",
          "warmup-iterations": 500,
          "iterations": 100,
          "target-throughput": 8
        },
        {
          "operation": "term",
          "warmup-iterations": 500,
          "iterations": 100,
          "target-throughput": 50
        },
        {
          "operation": "range",
          "warmup-iterations": 100,
          "iterations": 100,
          "target-throughput": 1
        },
        {
          "operation": "hourly_agg",
          "warmup-iterations": 100,
          "iterations": 100,
          "target-throughput": 0.2
        },
        {
          "operation": "scroll",
          "warmup-iterations": 100,
          "iterations": 200,
          "#COMMENT": "Throughput is considered per request. So we issue one scroll request per second which will retrieve 25 pages",
          "target-throughput": 1
        },
        {
          "operation": "desc_sort_timestamp",
          "warmup-iterations": 200,
          "iterations": 100,
          "target-throughput": 0.5
        },
        {
          "operation": "asc_sort_timestamp",
          "warmup-iterations": 200,
          "iterations": 100,
          "target-throughput": 0.5
        },
        {
          "name": "force-merge-1-seg",
          "operation": {
            "operation-type": "force-merge",
            "max-num-segments": 1,
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge-1-seg",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-1-seg-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        },
        {
          "name": "desc-sort-timestamp-after-force-merge-1-seg",
          "operation": "desc_sort_timestamp",
          "warmup-iterations": 200,
          "iterations": 100,
          "target-throughput": 2
        },
        {
          "name": "asc-sort-timestamp-after-force-merge-1-seg",
          "operation": "asc_sort_timestamp",
          "warmup-iterations": 200,
          "iterations": 100,
          "target-throughput": 2
        }
      ]
    },
    {
      "name": "append-no-conflicts-index-only",
      "description": "Indexes the whole document corpus using Elasticsearch default settings. We only adjust the number of replicas as we benchmark a single node cluster and Rally will only start the benchmark if the cluster turns green. Document ids are unique so all index operations are append only.",
      "schedule": [
        {
          "operation": "delete-index"
        },
        {
          "operation": {
            "operation-type": "create-index",
            "settings": {{index_settings | default({}) | tojson}}
          }
        },
        {
          "name": "check-cluster-health",
          "operation": {
            "operation-type": "cluster-health",
            "index": "logs-*",
            "request-params": {
              "wait_for_status": "{{cluster_health | default('green')}}",
              "wait_for_no_relocating_shards": "true"
            }
          }
        },
        {
          "operation": "index-append",
          "warmup-time-period": 240,
          "clients": {{bulk_indexing_clients | default(8)}}
        },
        {
          "name": "refresh-after-index",
          "operation": "refresh"
        },
        {
          "operation": {
            "operation-type": "force-merge",
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        }
      ]
    },
    {
      "name": "append-sorted-no-conflicts",
      "description": "Indexes the whole document corpus in an index sorted by timestamp field in descending order (most recent first) and using a setup that will lead to a larger indexing throughput than the default settings. Document ids are unique so all index operations are append only.",
      "schedule": [
        {
          "operation": "delete-index"
        },
        {
          "operation": {
            "operation-type": "create-index",
            "settings": {%- if index_settings is defined %} {{index_settings | tojson}} {%- else %} {
              "index.sort.field": "@timestamp",
              "index.sort.order": "desc"
            }{%- endif %}
          }
        },
        {
          "name": "check-cluster-health",
          "operation": {
            "operation-type": "cluster-health",
            "index": "logs-*",
            "request-params": {
              "wait_for_status": "{{cluster_health | default('green')}}",
              "wait_for_no_relocating_shards": "true"
            }
          }
        },
        {
          "operation": "index-append",
          "warmup-time-period": 240,
          "clients": {{bulk_indexing_clients | default(8)}}
        },
        {
          "name": "refresh-after-index",
          "operation": "refresh"
        },
        {
          "operation": {
            "operation-type": "force-merge",
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        }
      ]
    },
    {
      "name": "append-index-only-with-ingest-pipeline",
      "description": "Indexes the whole document corpus using Elasticsearch default settings. We only adjust the number of replicas as we benchmark a single node cluster and Rally will only start the benchmark if the cluster turns green. Document ids are unique so all index operations are append only. Runs the documents through an ingest node pipeline to parse the http logs. May require --elasticsearch-plugins='ingest-geoip' ",
      "schedule": [
        {
          "operation": "delete-index"
        },
        {
          "operation": {
            "operation-type": "create-index",
            "settings": {{index_settings | default({}) | tojson}}
          }
        },
        {
          "name": "check-cluster-health",
          "operation": {
            "operation-type": "cluster-health",
            "index": "logs-*",
            "request-params": {
              "wait_for_status": "{{cluster_health | default('green')}}",
              "wait_for_no_relocating_shards": "true"
            }
          }
        },
        {
        "operation": "create-http-log-{{ingest_pipeline | default('baseline')}}-pipeline"
        },
        {
          "operation": "index-append-with-ingest-{{ingest_pipeline | default('baseline')}}-pipeline",
          "warmup-time-period": 240,
          "clients": {{bulk_indexing_clients | default(8)}}
        },
        {
          "name": "refresh-after-index",
          "operation": "refresh"
        },
        {
          "operation": {
            "operation-type": "force-merge",
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        }
      ]
    },
    {
      "name": "update",
      "schedule": [
        {
          "operation": "delete-index"
        },
        {
          "operation": {
            "operation-type": "create-index",
            "settings": {%- if index_settings is defined %} {{index_settings | tojson}} {%- else %} {
              "index.number_of_shards": {{number_of_shards | default(1)}},
              "index.number_of_replicas": {{number_of_replicas | default(0)}},
              "index.store.type": "{{store_type | default('fs')}}"
            }{%- endif %}
          }
        },
        {
          "name": "check-cluster-health",
          "operation": {
            "operation-type": "cluster-health",
            "index": "logs-*",
            "request-params": {
              "wait_for_status": "{{cluster_health | default('green')}}",
              "wait_for_no_relocating_shards": "true"
            }
          }
        },
        {
          "operation": "update",
          "warmup-time-period": 240,
          "clients": {{bulk_indexing_clients | default(8)}}
        },
        {
          "name": "refresh-after-index",
          "operation": "refresh"
        },
        {
          "operation": {
            "operation-type": "force-merge",
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        }
      ]
    },
    {
      "name": "append-no-conflicts-index-reindex-only",
      "description": "Indexes the whole document corpus using Elasticsearch default settings. We only adjust the number of replicas as we benchmark a single node cluster and Rally will only start the benchmark if the cluster turns green. Document ids are unique so all index operations are append only. After indexing, same data are reindexed.",
      "schedule": [
        {
          "operation": "delete-index"
        },
        {
          "operation": {
            "operation-type": "create-index",
            "settings": {{index_settings | default({}) | tojson}}
          }
        },
        {
          "name": "check-cluster-health",
          "operation": {
            "operation-type": "cluster-health",
            "index": "logs-*",
            "request-params": {
              "wait_for_status": "{{cluster_health | default('green')}}",
              "wait_for_no_relocating_shards": "true"
            }
          }
        },
        {
          "operation": "index-append",
          "warmup-time-period": 240,
          "clients": {{bulk_indexing_clients | default(8)}}
        },
        {
          "name": "refresh-after-index",
          "operation": "refresh"
        },
        {
          "operation": {
            "operation-type": "force-merge",
            "request-timeout": 7200
          }
        },
        {
          "name": "refresh-after-force-merge",
          "operation": "refresh"
        },
        {
          "name": "wait-until-merges-finish",
          "operation": {
            "operation-type": "index-stats",
            "index": "_all",
            "condition": {
              "path": "_all.total.merges.current",
              "expected-value": 0
            },
            "retry-until-success": true,
            "include-in-reporting": false
          }
        },
        {
          "name": "reindex",
          "operation": {
            "operation-type": "reindex",
            "body": {
              "source": {
                "index": "logs-*"
              },
              "dest": {
                "index": "reindexed-logs"
              }
            },
            "request_timeout": 7200
          }
        }
      ]
    }

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
elasticsearch压力测试工具之ESrally使用说明
esrally是elastic search官方用于对ES集群进行压力测试的工具,使用esrally可以为我们构建不同版本集群,构造不同的参数和数据来进行压力测试,并且可以对产生的压测结果进行比较,rally顾名思义是拉力赛的意思,esrally的一些名词也都与拉力赛有关。 github地址:https://github.com/elastic/rally
没有故事的陈师傅
2020/08/31
2.1K0
ElasticSearch最全详细使用教程:入门、索引管理、映射详解
导读:本文介绍了ElasticSearch的必备知识:从入门、索引管理到映射详解。
java思维导图
2019/12/03
86.4K0
Elasticsearch调优实践
本文基于ES 5.6.4,从性能和稳定性两方面,从linux参数调优、ES节点配置和ES使用方式三个角度入手,介绍ES调优的基本方案。当然,ES的调优绝不能一概而论,需要根据实际业务场景做适当的取舍和调整,文中的疏漏之处也随时欢迎批评指正。
老生姜
2018/11/07
1.6K0
Elasticsearch调优实践
Elastic Stack最佳实践:7.10.1与7.14.2的性能比较
我们知道,最近腾讯云Elasticsearch service上提供了新版本7.14.2,这次版本更新较为低调,相对于原厂每月发版的节奏,国内的云厂商相对比较谨慎,通常是在原厂版本发布多月之后,才会选择一个稳定的版本在公有云的托管服务上提供版本更新。相对而言,7.14.2已经是国内各大云厂商上能够使用到的最新的Elasticsearch版本了。但尽管如此,仍然有不少用户疑问,从7.10.1升级到7.14.2是否值得更新,能带来哪些收益,是否会有问题。因此,这里会通过几篇文章,给大家介绍7.10.1升级到7.14.2,期间两个版本的主要不同。
点火三周
2022/03/20
1.7K0
Elastic Stack最佳实践:7.10.1与7.14.2的性能比较
esrally 如何进行简单的自定义性能测试?
Rally 最初于 2016 年发布,直到 2018 年 7 月才发布 1.0 版本,Rally 工具 是 Elasticsearch 开发团队用来运行夜间基准测试的工具。
铭毅天下
2022/04/06
2.2K0
esrally 如何进行简单的自定义性能测试?
通过 esrally 压测elasticsearch
esrally官方文档: https://esrally.readthedocs.io/en/latest/configuration.html
保持热爱奔赴山海
2019/12/10
1.2K0
干货 | Elasticsearch Top10 监控指标
Elasticsearch具有通用性,可扩展性和实用性的特点,集群的基础架构必须满足如上特性。合理的集群架构能支撑其数据存储及并发响应需求。相反,不合理的集群基础架构和错误配置可能导致集群性能下降、集群无法响应甚至集群崩溃。
铭毅天下
2019/05/16
6.8K0
干货 | Elasticsearch Top10 监控指标
Elasticsearch 6.0.0本地单机16核32G压测报告
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。
岳涛
2021/10/20
1.9K3
Elasticsearch 6.0.0本地单机16核32G压测报告
“Hot-Warm” Architecture in Elasticsearch 5.x
When using elasticsearch for larger time data analytics use cases, we recommend using time-based indices and a tiered architecture with 3 different types of nodes (Master, Hot-Node and Warm-Node), which we refer to as the "Hot-Warm" architecture. Each node has their own characteristics, which are described below.
heidsoft
2019/05/28
7000
Elasticsearch 7.10.1集群压测报告(4核16G*3,Intel)
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。
岳涛
2021/10/21
9880
Elasticsearch 7.10.1集群压测报告(4核16G*3,Intel)
Prometheus系列 | 监控elasticsearch
启动成功后,可以访问 http://192.168.50.153:9109/metrics ,看抓取的信息
SY小站
2020/07/03
4.3K0
Elastic Searchable snapshot功能初探 三 (frozen tier)
3月23号,Elastic又发布了最新的7.12版本。在这个版本中,最重要的一个更新是frozen tier的发布。相比于之前版本的cold tier(关于cold tier的细节,可以查看之前的博文:Elastic Searchable snapshot功能初探、Elastic Searchable snapshot功能初探 二 (hot phase)),其最大的不同是我们可以直接在对象存储里面进行数据的搜索,即我们能够保持对象存储里面的快照数据一直在线可查,通过构建一个小规模的,只带基础存储的计算集群,就可以查阅保存在快照中的海量数据!做到真正的计算和存储分离,并且极大的降低查阅庞大的历史冷冻数据的所需的成本和提高查询效能。(可参考官方博客:使用新的冻结层直接搜索S3)
点火三周
2021/04/02
7K0
Elastic Searchable snapshot功能初探 三 (frozen tier)
Elasticsearch压测之Esrally压测标准
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。
岳涛
2021/11/15
3.8K7
Elasticsearch压测之Esrally压测标准
Elasticsearch压测工具Esrally部署之踩坑实录(下)
本文描述问题及解决方法同样适用于 腾讯云 Elasticsearch Service(ES)。
岳涛
2021/10/21
3.3K0
Elasticsearch压测工具Esrally部署之踩坑实录(下)
Elasticsearch merge 你懂了吗?
由于自动refresh过程每秒钟都会创建一个新的segment,不需要很长时间,segment的数量就会爆炸性增长。拥有太多的segment会严重影响ES的性能及查询效率。每个segment都会消耗文件句柄、内存和CPU等。更重要的是,每个搜索请求都必须依次检查每个段;segment越多,搜索速度就越慢。因此,如何制定合理的merge 策略以及如何自动的进行force merge是每个ES运维人员都必须学会的关键技能。
雨夜v1
2021/07/14
6.8K3
Elasticsearch merge 你懂了吗?
让Elasticsearch飞起来!百亿级实时查询优化实战
经过对 Elasticsearch 多方调研和超过几百亿条数据的插入和聚合查询的验证之后,我们总结出以下几种能够有效提升性能和解决这一问题的方案:
猿天地
2019/06/18
1.7K0
万字超全 ElasticSearch 监控指南
导语:本文详细介绍了 ElasticSearch 如搜索性能指标、索引性能指标、内存使用和垃圾回收指标等六类监控关键指标、集群和索引两类大盘配置示例,以及 ES 在查询性能差、索引性能差的两种典型问题场景下详细的原因、排查方式和解决方案,同时也介绍了如何通过 Prometheus 监控搭建可靠的监控系统,详尽全面,推荐给大家,也欢迎各位一起交流。
腾讯技术工程官方号
2024/03/20
9720
万字超全 ElasticSearch 监控指南
ElasticSearch 配置文件译文解析
##################### ElasticSearch 配置示例 #####################
星哥玩云
2022/07/04
3280
ELK运维文档
用于查看Node级别的基本信息,选参数为pipelines、os和jvm,如下查看基本的os和jvm信息:
charlieroro
2024/01/26
8420
ELK运维文档
【ElasticSearch性能测试】esrally最新版本的编译、安装与使用
在使用esrally 1.4.1进行性能测试的过程中发现,如果使用geonames数据集,且ES集群版本是7.x,则测试进行到一半,就会报错,如:
BH8ANK
2021/01/05
2.8K0
【ElasticSearch性能测试】esrally最新版本的编译、安装与使用
相关推荐
elasticsearch压力测试工具之ESrally使用说明
更多 >
领券
社区富文本编辑器全新改版!诚邀体验~
全新交互,全新视觉,新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能,全面提升创作效率和体验
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档
查看详情【社区公告】 技术创作特训营有奖征文