1. 性能优化与容量治理总览

Elasticsearch 的性能问题很少是单一原因造成的。多数线上故障表现为“查询变慢、写入堆积、节点掉线”，但根因往往分布在数据模型、分片布局、查询写法、JVM 内存、磁盘 I/O、线程池与集群拓扑等多个层面。容量治理的目标不是把集群压到极限，而是在可预期的业务增长下，让集群在延迟、吞吐、稳定性和成本之间保持可控的平衡。本章先建立一张全局地图：性能问题从哪里来、容量治理看哪些指标、后续 29 章按什么路径展开，以及实战环境如何准备。

一、性能问题的常见来源

从工程视角看，Elasticsearch 的性能压力可以归为五类来源，它们经常互相叠加：

• 写入侧：分片数过多导致集群状态膨胀；refresh_interval 过短造成频繁生成 segment；bulk 批次过小或过大；副本同步与 translog 刷盘争抢磁盘；mapping 中大量 text 字段开启 fielddata。
• 查询侧：深分页 from+size 过大；通配符前缀查询、正则、script 查询；聚合基数过高；一次召回大量字段；未使用 filter 导致无法利用缓存。
• 存储与硬件：磁盘 IOPS 不足、堆外内存与 page cache 竞争、SSD 寿命与写放大、网络带宽成为副本同步瓶颈。
• JVM 与线程池：堆过大导致 GC 停顿长；堆过小导致频繁 Young GC；write/search 队列满触发拒绝；熔断器触发后查询直接失败。
• 集群拓扑与治理：主分片分布不均、热点分片、节点角色混布、跨机房副本同步、索引生命周期策略缺失导致冷热数据混存。

这些问题在监控上会呈现不同的信号：写入侧通常表现为 indexing latency 上升、refresh 次数激增；查询侧表现为 search latency 与 rejected 增加；JVM 侧表现为 old GC 时间占比升高；存储侧表现为 iowait 与磁盘队列深度上升。识别信号与来源的对应关系，是排障的第一步。

二、容量治理的目标与关键指标

容量治理要回答三个问题：当前集群能承载多少业务量？业务增长到下一阶段需要多少资源？在成本约束下如何分配资源？因此它关注的不是单一指标，而是一组相互制约的指标。

第一组是延迟类指标：写入 indexing latency、查询 search latency 的 p50/p95/p99。平均值容易被长尾掩盖，容量评估必须看 p95 与 p99。第二组是吞吐类指标：indexing rate（docs/s）、search rate（query/s）、bulk 队列长度。第三组是资源类指标：CPU 使用率、磁盘 IOPS 与吞吐、JVM 堆使用率、old GC 时间占比、page cache 命中率。第四组是稳定性指标：线程池 rejected 次数、熔断触发次数、节点离线次数、分片恢复时长。第五组是成本指标：单 GB 存储成本、冷热数据比例、副本冗余度。

这些指标之间存在明确的约束关系。例如，把 refresh_interval 从 30s 调到 1s，写入可见性变好，但 segment 数量与 merge 压力上升，磁盘 IOPS 与 CPU 都会增加；把副本数从 1 调到 2，查询吞吐可能提升，但写入放大 3 倍，存储成本增加 50%。容量治理的本质，是在这些约束下做取舍，而不是追求每个指标都最优。

三、课程整体学习路径

本课程共 30 章，按“认知—诊断—优化—治理—实战”五段推进。前几章建立性能与容量的全局认知，包括问题来源、指标体系和环境准备；随后进入诊断阶段，学习如何用 _nodes/stats、_cat/indices、hot_threads、profile API 等工具定位瓶颈；优化阶段分别覆盖写入、查询、mapping、分片、JVM、线程池与缓存；治理阶段讨论索引生命周期、冷热分层、快照与恢复、容量水位与成本控制；最后通过综合实战把前面的方法串成完整闭环。

学习路径不是线性的。实际工作中，你很可能先遇到查询变慢，再回头检查分片与 mapping；也可能先做容量扩容，再发现写入瓶颈来自 refresh 策略。因此每一章都会给出可独立使用的检查项与参数示例，方便按需查阅。

四、实战环境准备

为了让后续章节的示例可以直接复现，建议准备一套最小可用的实验环境。以下配置属于教学示例，可根据本机资源调整：

# docker-compose.yml 示例（单节点，仅用于学习）
version: "3.8"
services:
  es01:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.13.0
    container_name: es01
    environment:
      - node.name=es01
      - discovery.type=single-node
      - xpack.security.enabled=false
      - ES_JAVA_OPTS=-Xms2g -Xmx2g
      - bootstrap.memory_lock=true
    ulimits:
      memlock: { soft: -1, hard: -1 }
    ports:
      - "9200:9200"
    volumes:
      - esdata01:/usr/share/elasticsearch/data

volumes:
  esdata01:

启动后可用以下命令确认集群状态与基础指标：

curl -s localhost:9200/_cluster/health?pretty
curl -s localhost:9200/_cat/nodes?v&h=name,heap.percent,ram.percent,cpu,load_1m
curl -s localhost:9200/_cat/indices?v&h=index,health,pri,rep,docs.count,store.size

建议同时准备一份压测数据。可以用官方 rally 工具，也可以先用 bulk 写入一批日志类文档，观察 indexing rate、refresh 次数与 segment 数量变化。后续章节会反复使用这套环境验证参数调整效果。

准备就绪后，先记录一组基线数据：空集群的堆使用率、磁盘可用空间、默认 refresh_interval、分片数。后续每次调整参数或查询写法，都与这组基线对比，才能判断优化是否真正有效。容量治理的第一步，永远是先看清现状。