Elasticsearch搜索引擎实战教程

本文集文档发布于灏天文库

8.6 性能调优 (Performance Tuning)

文档摘要

8.6 性能调优 (Performance Tuning) Elasticsearch 性能调优：集群管理与运维实战指南 性能调优概览 Elasticsearch 性能调优是一个多维度、系统性的工程，涉及硬件资源、配置参数、索引设计、查询优化等多个方面。从集群管理与运维的角度来看，性能调优的目标主要集中在以下几个方面： 提升索引写入速度 (Indexing Performance): 加快数据导入速度，缩短数据可见时间。 优化查询响应速度 (Search Performance): 降低查询延迟，提升用户搜索体验。 保障集群稳定性 (Cluster Stability): 避免资源瓶颈，防止集群宕机或性能大幅下降。 在 8.

8.6 性能调优 (Performance Tuning)

Elasticsearch 性能调优：集群管理与运维实战指南

1. 性能调优概览

Elasticsearch 性能调优是一个多维度、系统性的工程，涉及硬件资源、配置参数、索引设计、查询优化等多个方面。从集群管理与运维的角度来看，性能调优的目标主要集中在以下几个方面：

  • 提升索引写入速度 (Indexing Performance): 加快数据导入速度，缩短数据可见时间。

  • 优化查询响应速度 (Search Performance): 降低查询延迟，提升用户搜索体验。

  • 保障集群稳定性 (Cluster Stability): 避免资源瓶颈，防止集群宕机或性能大幅下降。

在 8.6 版本中，Elasticsearch 提供了丰富的工具和配置选项，让我们能够精细化地控制集群行为，实现性能优化。

2. 硬件资源优化

硬件资源是 Elasticsearch 性能的基础。合理的硬件配置能够为性能调优奠定坚实的基础。

2.1 CPU

CPU 主要负责 Lucene 索引的构建、查询的执行、以及集群内部的协调工作。对于 Elasticsearch 节点，特别是数据节点和 Master 节点，需要充足的 CPU 资源。

  • 核心数量: 更多的 CPU 核心可以并行处理更多的任务，提升整体吞吐量。建议选择多核 CPU。

  • 主频: 较高的主频可以加速单个任务的执行速度，对于复杂查询或高并发场景有帮助。

实践建议:

  • 监控 CPU 使用率: 使用 GET _nodes/stats/os API 或监控工具 (如 Prometheus + Grafana) 监控 CPU 使用率。如果 CPU 经常处于高负载状态，可能需要考虑升级 CPU 或增加节点数量。

    GET _nodes/stats/os?filter_path=**.cpu
​

  • 避免 CPU 密集型操作: 尽量避免在 Elasticsearch 中进行复杂的计算操作，例如过度的脚本使用。

2.2 内存 (RAM)

内存对于 Elasticsearch 性能至关重要。Elasticsearch 主要使用内存进行以下几个方面：

  • JVM Heap: 用于存储 Lucene 索引数据结构、缓存和执行查询。

  • 操作系统缓存 (Page Cache): 用于缓存磁盘上的索引数据，加速 I/O 操作。

实践建议:

  • 合理配置 JVM Heap: JVM Heap 大小直接影响 Elasticsearch 的性能和稳定性。通常建议将 JVM Heap 设置为服务器总内存的 50%，但不超过 32GB (对于压缩对象指针技术的 JVM)。在 jvm.options 文件中配置 -Xms 和 -Xmx 参数。

    # jvm.options
-Xms16g
-Xmx16g
​

    • -Xms (Initial Heap Size): JVM 启动时分配的初始堆大小。

    • -Xmx (Maximum Heap Size): JVM 可以使用的最大堆大小。

    重要提示: -Xms 和 -Xmx 应该设置为相同的值，以避免 JVM 动态调整堆大小带来的性能开销。

  • 监控 JVM Heap 使用率: 使用 GET _nodes/stats/jvm API 或监控工具监控 JVM Heap 使用情况，确保 Heap 大小设置合理，避免频繁的 Full GC。

    GET _nodes/stats/jvm?filter_path=**.heap
​

  • 操作系统缓存: Elasticsearch 依赖操作系统缓存来加速磁盘 I/O。确保有足够的内存留给操作系统缓存。

2.3 存储 (Disk)

磁盘 I/O 速度是 Elasticsearch 性能的瓶颈之一，特别是对于索引写入和查询操作。

  • SSD (固态硬盘): SSD 具有更高的读写速度和更低的延迟，强烈推荐用于 Elasticsearch 集群，特别是数据节点。

  • HDD (机械硬盘): 如果预算有限，可以使用 HDD，但需要考虑其较低的 I/O 性能。

实践建议:

  • 选择 SSD: 优先选择 SSD 作为 Elasticsearch 数据存储介质，以获得最佳性能。

  • RAID 0 或 JBOD: 对于数据节点，可以使用 RAID 0 或 JBOD (Just a Bunch of Disks) 模式，以提升磁盘吞吐量。 注意: RAID 0 不提供数据冗余，JBOD 则依赖 Elasticsearch 的副本机制来保证数据安全。

  • 监控磁盘 I/O: 使用 iostat 命令或监控工具监控磁盘 I/O 性能。如果磁盘 I/O 成为瓶颈，需要考虑升级磁盘或优化索引设计。

    iostat -x 1
​

  • 磁盘空间规划: 合理规划磁盘空间，预留足够的空间用于索引增长和集群操作 (如合并段)。可以使用 GET _cat/allocation?v API 查看磁盘使用情况。

    GET _cat/allocation?v
​

2.4 网络

网络带宽和延迟影响集群节点之间的通信效率，特别是对于跨节点查询和数据传输。

实践建议:

  • 高速网络: 建议使用千兆或万兆网络，确保节点之间通信畅通。

  • 低延迟网络: 尽量减少网络延迟，避免节点之间距离过远。

  • 监控网络指标: 使用 netstat 命令或监控工具监控网络流量和延迟。

    netstat -s
​

3. Elasticsearch 配置调优

Elasticsearch 提供了丰富的配置选项，通过调整这些配置参数，可以优化集群性能。

3.1 JVM 调优

JVM 调优主要集中在垃圾回收 (Garbage Collection, GC) 策略和 JVM 选项的设置上。

  • G1GC (Garbage-First Garbage Collector): Elasticsearch.x 默认使用 G1GC，它是一种面向服务端应用的垃圾回收器，旨在实现高吞吐量和低延迟。通常情况下，G1GC 的默认配置已经足够优秀，无需过多调整。

  • JVM 选项: 除了 -Xms 和 -Xmx，还可以根据实际情况调整其他 JVM 选项，例如：

    • -XX:+UseConcMarkSweepGC (CMS 垃圾回收器，适用于老版本，8.x 已不推荐)

    • -XX:G1ReservePercent=25 (G1GC 保留内存百分比)

    • -XX:InitiatingHeapOccupancyPercent=45 (G1GC 触发并发 GC 的堆占用率)

实践建议:

  • 监控 GC 日志: 启用 GC 日志，分析 GC 行为，判断是否需要调整 JVM 参数。可以在 jvm.options 中配置 GC 日志参数。

    # jvm.options
-Xlog:gc*,gc+age=trace:file=gc.log:utctime,pid,tags:filecount=32,filesize=64m
​

  • 避免 Full GC: 频繁的 Full GC 会导致 Elasticsearch 性能大幅下降甚至集群卡顿。通过监控 JVM Heap 和 GC 日志，优化 JVM 配置，减少 Full GC 的发生。

3.2 线程池调优 (Thread Pools)

Elasticsearch 使用线程池来管理并发任务，例如索引写入、查询、Bulk 请求等。合理的线程池配置可以提升并发处理能力。

  • index 线程池: 用于索引写入操作。

    • index.indexing.threads.max: 最大索引线程数 (默认自动调整)。

    • index.indexing.threads.queue_size: 索引线程队列大小 (默认 -1，无限制)。

  • search 线程池: 用于查询操作。

    • thread_pool.search.size: 搜索线程池大小 (默认 CPU 核心数 + 队列大小)。

    • thread_pool.search.queue_size: 搜索线程队列大小 (默认 1000)。

  • bulk 线程池: 用于 Bulk 请求操作。

    • thread_pool.bulk.size: Bulk 线程池大小 (默认 CPU 核心数 + 队列大小)。

    • thread_pool.bulk.queue_size: Bulk 线程队列大小 (默认 50)。

  • get 线程池: 用于 Get 请求操作。

    • thread_pool.get.size: Get 线程池大小 (默认 CPU 核心数 + 队列大小)。

    • thread_pool.get.queue_size: Get 线程队列大小 (默认 1000)。

实践建议:

  • 监控线程池队列: 使用 GET _nodes/thread_pool API 监控线程池队列情况。如果队列经常满，可能需要调整线程池大小。

    GET _nodes/thread_pool?filter_path=**.threads,**.queue
​

  • 根据负载调整线程池大小: 对于索引密集型应用，可以适当增加 index 线程池大小。对于查询密集型应用，可以适当增加 search 线程池大小。

    PUT _cluster/settings
{
  "persistent": {
    "thread_pool": {
      "search": {
        "size": 32,
        "queue_size": 2000
      }
    }
  }
}
​

    注意: 线程池大小并非越大越好，过大的线程池会增加线程切换开销，反而可能降低性能。需要根据实际负载进行测试和调整。

3.3 索引刷新间隔 (Refresh Interval)

索引刷新 (Refresh) 操作将内存中的索引段 (Segment) 刷新到磁盘并使其可搜索。刷新操作会消耗 I/O 资源，影响索引写入速度。

  • index.refresh_interval: 控制索引刷新的频率。默认值为 1s (每秒刷新一次)。

实践建议:

  • 调整刷新间隔: 对于写入密集型应用，可以适当增加刷新间隔，例如设置为 30s 或 60s，以降低 I/O 压力，提升索引写入速度。

    PUT index_name/_settings
{
  "index": {
    "refresh_interval": "30s"
  }
}
​

    注意: 增加刷新间隔会延迟数据可见时间。需要在写入性能和实时性之间进行权衡。

  • 批量刷新: 在 Bulk 写入操作后，可以手动执行刷新操作，例如 _bulk?refresh=wait_for，确保数据及时可见。

3.4 Translog 设置

Translog (事务日志) 用于持久化索引操作，确保数据在节点故障时不会丢失。Translog 的设置会影响数据安全性和写入性能。

  • index.translog.durability: 控制 Translog 的持久化级别。

    • request (默认值): 每次索引操作后都将 Translog 刷新到磁盘，数据安全性高，但写入性能较低。

    • async: 异步刷新 Translog 到磁盘，数据安全性略低，但写入性能较高。

  • index.translog.sync_interval: 控制异步刷新 Translog 的时间间隔 (默认 5s)。

实践建议:

  • 根据数据安全需求选择 durability: 对于数据安全性要求高的场景，使用 request 模式。对于写入性能要求高的场景，可以考虑使用 async 模式。

  • 调整 sync_interval: 在 async 模式下，可以适当调整 sync_interval，平衡数据安全性和写入性能。

3.5 索引缓冲区 (Indexing Buffer)

索引缓冲区用于缓存索引数据，提升索引写入速度。

  • indices.memory.index_buffer_size: 控制节点级别的索引缓冲区总大小 (默认 10% JVM Heap，最小 48MB，最大无限制)。

  • index.indexing.slowlog.threshold.index.warn: 索引慢日志阈值，用于监控索引写入性能。

实践建议:

  • 调整索引缓冲区大小: 对于写入密集型应用，可以适当增加索引缓冲区大小，提升索引写入吞吐量。

    PUT _cluster/settings
{
  "persistent": {
    "indices": {
      "memory": {
        "index_buffer_size": "20%"
      }
    }
  }
}
​

  • 监控索引慢日志: 配置索引慢日志，监控索引写入性能，及时发现和解决性能问题。

    PUT index_name/_settings
{
  "index": {
    "indexing": {
      "slowlog": {
        "threshold": {
          "index": {
            "warn": "5s",
            "trace": "500ms"
          }
        },
        "source": "1000"
      }
    }
  }
}
​

3.6 熔断器 (Circuit Breakers)

熔断器用于防止 Elasticsearch 发生 OutOfMemoryError (OOM) 错误。当某些操作 (如查询、数据加载) 消耗的内存超过预设阈值时，熔断器会触发，阻止操作执行，保护集群稳定性。

  • indices.breaker.request.limit: 请求熔断器限制 (默认 JVM Heap 的 60%)。

  • indices.breaker.fielddata.limit: Fielddata 熔断器限制 (默认 JVM Heap 的 60%)。

  • indices.breaker.in_flight_requests.limit: 正在处理的请求熔断器限制 (默认 JVM Heap 的 100%)。

  • indices.breaker.accounting.limit: Accounting 熔断器限制 (默认 JVM Heap 的 70%)。

实践建议:

  • 监控熔断器状态: 使用 GET _nodes/stats/breakers API 监控熔断器触发情况。

    GET _nodes/stats/breakers
​

  • 合理配置熔断器阈值: 默认的熔断器阈值通常已经足够安全。在特殊情况下，可以根据实际需求调整熔断器阈值，但需要谨慎操作，避免降低集群稳定性。

4. 索引设计优化

合理的索引设计是提升 Elasticsearch 性能的关键。

4.1 Mapping 优化

  • 选择合适的数据类型: 为字段选择最合适的数据类型，避免过度使用 keyword 类型，合理使用 text 类型并配置 analyzer。

  • 禁用不需要的字段: 如果某些字段不需要被搜索或聚合，可以禁用 index 属性，减少索引大小和资源消耗。

  • 使用 doc_values 或 fielddata: 对于需要聚合或排序的字段，启用 doc_values (默认启用) 或 fielddata (text 类型字段)。doc_values 更高效，推荐使用。

  • 合理配置 norms: 对于不需要计算文档评分的字段，可以禁用 norms，减少索引大小。

实践建议:

  • 仔细设计 Mapping: 在索引创建前，仔细分析业务需求，设计合理的 Mapping 结构。

  • 使用 Index Templates: 使用 Index Templates 管理索引 Mapping，方便统一管理和维护。

    PUT _index_template/my-template
{
  "index_patterns": ["my-index-*"],
  "template": {
    "mappings": {
      "properties": {
        "timestamp": {
          "type": "date"
        },
        "message": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }
          }
        }
      }
    }
  }
}
​

4.2 Shard 优化

  • 合理分配 Shard 数量: Shard 数量过多会增加集群管理开销，Shard 数量过少可能导致单个 Shard 过大，影响查询性能。

  • 控制 Shard 大小: 建议单个 Shard 的大小控制在 30GB-50GB 左右。

  • 使用 Replica Shard: 配置 Replica Shard 提高数据可用性和查询吞吐量。

实践建议:

  • 根据数据量和集群规模调整 Shard 数量: 在索引创建时，根据数据量和集群规模合理规划 Shard 数量。可以使用 Index Templates 统一管理 Shard 设置。

    PUT _index_template/my-template
{
  "index_patterns": ["my-index-*"],
  "template": {
    "settings": {
      "index": {
        "number_of_shards": 3,
        "number_of_replicas": 1
      }
    }
  }
}
​

  • 监控 Shard 大小: 使用 GET _cat/shards?v API 监控 Shard 大小，及时发现过大的 Shard 并进行调整。

    GET _cat/shards?v
​

4.3 Segment 优化

Lucene 索引由多个 Segment 组成。Segment 合并 (Merge) 操作可以将多个小 Segment 合并成一个大的 Segment，减少 Segment 数量，提升查询性能。

  • 自动 Segment 合并: Elasticsearch 会自动进行 Segment 合并操作。

  • 手动触发 Segment 合并: 可以使用 _forcemerge API 手动触发 Segment 合并。

实践建议:

  • 合理配置 Segment 合并策略: Elasticsearch 默认的 Segment 合并策略通常已经足够优秀。

  • 在低峰期手动触发 Segment 合并: 在索引写入低峰期，可以手动触发 _forcemerge API，优化索引结构。

    POST index_name/_forcemerge?max_num_segments=1
​

    注意: Segment 合并操作会消耗大量 I/O 资源，建议在低峰期执行。

5. 查询优化

查询优化是提升搜索性能的关键环节。

5.1 Profile API

Profile API 可以分析查询的执行过程，找出查询瓶颈。

实践建议:

  • 使用 Profile API 分析慢查询: 对于慢查询，使用 Profile API 分析查询的各个阶段的耗时，找出性能瓶颈。

    POST index_name/_profile
{
  "query": {
    "match": {
      "message": "error"
    }
  }
}
​

    分析 Profile API 的输出结果，重点关注耗时较长的部分，例如：rewrite_time, collect_time, build_scorer_time, create_weight_time, search_time 等。

5.2 Query 优化

  • 避免使用通配符查询 (Wildcard Query) 和正则表达式查询 (Regexp Query): 这类查询性能较差，尽量避免使用。

  • 使用 Filter Context 替代 Query Context: 对于不需要计算文档评分的查询 (例如 Term Query, Range Query, Filter Query 等)，使用 Filter Context，可以提升查询性能。

  • 合理使用 Cache: Elasticsearch 提供了多种 Cache 机制，例如 Node Query Cache, Shard Request Cache, Fielddata Cache 等。合理利用 Cache 可以提升查询性能。

  • 避免深度分页 (Deep Paging): 深度分页 (例如 from 和 size 参数过大) 性能较差，尽量避免使用。可以使用 Scroll API 或 Search After API 替代深度分页。

  • 优化 Script 查询: Script 查询性能较差，尽量避免使用。如果必须使用 Script 查询，尽量优化 Script 代码，减少计算量。

实践建议:

  • 优化 Query 语句: 根据 Profile API 的分析结果，优化 Query 语句，例如改写 Query 类型、调整 Query 参数、使用 Filter Context 等。

  • 测试不同 Query 语句的性能: 使用 Benchmark 工具 (例如 esrally) 测试不同 Query 语句的性能，选择最优的 Query 语句。

5.3 Cache 优化

  • Node Query Cache: 缓存查询结果，默认启用。可以通过 index.queries.cache.enabled 设置禁用。

  • Shard Request Cache: 缓存 Shard 级别的查询结果，默认禁用。可以通过 index.requests.cache.enable 设置启用。

  • Fielddata Cache: 缓存 Fielddata 数据，用于聚合和排序。默认禁用，通常不建议启用，除非有明确的性能需求。

  • 自动 Cache 清理: Elasticsearch 会自动清理 Cache，无需手动管理。

实践建议:

  • 根据查询模式调整 Cache 设置: 对于重复查询较多的场景，可以启用 Shard Request Cache，提升查询性能。

  • 监控 Cache 使用率: 使用 GET _nodes/stats/indices/query_cache 和 GET _nodes/stats/indices/request_cache API 监控 Cache 使用率。

    GET _nodes/stats/indices/query_cache
GET _nodes/stats/indices/request_cache
​

6. 集群监控与运维

性能调优是一个持续的过程，需要定期监控集群状态，及时发现和解决性能问题。

6.1 监控工具

  • Kibana Monitoring: Elasticsearch 自带的监控工具，可以监控集群状态、节点状态、索引状态、查询性能等。

  • Elasticsearch Exporter + Prometheus + Grafana: 使用 Elasticsearch Exporter 收集 Elasticsearch 指标，使用 Prometheus 存储指标数据，使用 Grafana 可视化指标数据。

6.2 慢日志 (Slow Logs)

Elasticsearch 提供了索引慢日志和搜索慢日志，用于记录执行时间超过阈值的索引和搜索操作。

  • 索引慢日志: index.indexing.slowlog.threshold.index.warn, index.indexing.slowlog.threshold.index.trace

  • 搜索慢日志: index.search.slowlog.threshold.query.warn, index.search.slowlog.threshold.query.trace

实践建议:

  • 配置慢日志: 启用索引慢日志和搜索慢日志，设置合适的阈值，监控慢操作。

    PUT index_name/_settings
{
  "index": {
    "indexing": {
      "slowlog": {
        "threshold": {
          "index": {
            "warn": "5s",
            "trace": "500ms"
          }
        },
        "source": "1000"
      }
    },
    "search": {
      "slowlog": {
        "threshold": {
          "query": {
            "warn": "10s",
            "trace": "1s"
          },
          "fetch": {
            "warn": "1s",
            "trace": "500ms"
          }
        },
        "source": "1000"
      }
    }
  }
}
​

  • 分析慢日志: 定期分析慢日志，找出慢操作的根源，并进行优化。

6.3 Hot Threads API

Hot Threads API 可以查看节点上正在运行的线程信息，找出 CPU 密集型线程，帮助定位性能瓶颈。

实践建议:

  • 使用 Hot Threads API 分析 CPU 瓶颈: 当 CPU 使用率过高时，使用 Hot Threads API 分析节点上正在运行的线程，找出 CPU 密集型线程。

    GET _nodes/hot_threads
​

6.4 资源监控

  • CPU 使用率: 监控 CPU 使用率，确保 CPU 资源充足。

  • 内存使用率: 监控 JVM Heap 和操作系统内存使用率，确保内存资源充足。

  • 磁盘 I/O: 监控磁盘 I/O 性能，避免磁盘 I/O 成为瓶颈。

  • 网络流量: 监控网络流量，确保网络带宽充足。

  • GC 频率和耗时: 监控 GC 频率和耗时，优化 JVM 配置，减少 Full GC 的发生。

  • 线程池队列长度: 监控线程池队列长度，调整线程池大小，避免任务堆积。

  • 熔断器触发次数: 监控熔断器触发次数，调整熔断器阈值或优化查询。

  • 慢日志数量: 监控慢日志数量，及时发现和解决性能问题。

7. 性能调优流程总结 (Mermaid 图)

图例说明:

  • 硬件资源评估: 评估当前硬件资源是否满足 Elasticsearch 性能需求。

  • 性能瓶颈分析: 分析集群性能瓶颈，确定是 CPU、内存、磁盘、网络还是 Elasticsearch 配置或索引设计问题。

  • 硬件资源优化: 针对硬件瓶颈进行优化，例如升级 CPU、增加内存、更换 SSD、升级网络等。

  • Elasticsearch 配置调优: 调整 Elasticsearch 配置参数，例如 JVM 参数、线程池大小、索引刷新间隔、Translog 设置等。

  • 索引设计优化: 优化索引 Mapping 结构、Shard 数量和大小、Segment 合并策略等。

  • 查询优化: 优化 Query 语句、利用 Cache 机制等。

  • 集群监控与运维: 部署监控工具、分析慢日志、使用 Hot Threads API、监控资源指标，持续监控和优化集群性能。

8. 总结

重要提示: 性能调优并非一蹴而就，需要不断学习、实践和总结经验。建议在进行任何配置更改前，务必进行充分的测试和评估，避免对生产环境造成负面影响。

作者与出处
原作者： 灏天文库
来源：灏天文库
整理： 灏天文库整理
由灏天文库平台收录，内容或由平台用户上传，仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U
0/500