做Elasticsearch性能调优最怕什么？怕别人上来就甩一句“你有没有推荐的参数配置”。我接手过一套日志检索平台，每天新增日志量3亿条左右，峰值写入每秒6万，查的主要是最近24小时内的错误日志和接口耗时分布。刚开始那段时间，集群隔三差五出问题：写入抖动、查询超时、GC频繁。折腾了快一个月，才把一套完整的调优方法论摸出来。这篇不是给你抄参数表的，我把思路、计算过程、踩过的坑一起讲清楚，适合正在维护ES集群、或者准备上ES做日志检索/搜索业务的人参考。

1. 开调前先把基线摸清楚：项目场景与问题拆解

1.1 我最初的集群状态和瓶颈

先交代一下当时的真实情况。集群有6个节点，每台是32核64GB内存、SSD磁盘，ES版本是7.x。索引按天滚动，每天一个索引，每个索引10个主分片、1个副本。写入用的是自研的日志采集程序，攒批后走Bulk接口。查询端是一些统计页面，按时间范围搜错误日志，有时候会翻到几千页之后。

刚开始的问题很典型：每天上午10点到下午2点是写入高峰，这个时段集群的CPU动不动就冲到80%以上，查询响应时间P99能到几十秒。看监控图就是一条锯齿线，刷一下上去，过一会又掉下来。最让人头疼的是深分页查询，一旦有人点了一个大时间范围的列表页，整个集群的GC就开始飙升。

这里要先说明一个核心观点：调优不能靠猜。第一件事是把基线数据摸清楚，包括节点配置、堆内存使用率、磁盘IO、分片数量、段数量、GC频率、查询P99。我当时拿Prometheus+Grafana搭了一套监控，把下面这些指标固化下来：

把这些数据列出来之后，问题就清晰了：分片偏大、段数量失控、查询方式有问题、写入策略没优化。这四个方向各自独立，可以分批次调整。如果不先做这一步，后面改任何参数都没有参照物，也不知道改完到底是变好还是变坏。

1.2 为什么一上来不要直接改参数

很多人在ES集群出问题之后第一反应是去网上搜“ES性能调优参数”，然后把一堆配置塞进elasticsearch.yml。这其实是最大的坑。每个集群的硬件、数据模型、查询模式都不一样，直接套用别人配置很可能适得其反。

举个我踩过的例子。网上有人说把index.refresh_interval调到-1能让写入翻倍，我当时直接照做，结果过了两小时业务方反馈说日志查不到了。原因很简单，refresh_interval设为-1意味着完全禁用刷新，写入的数据永远不会变成可搜索的段，必须手动执行refresh。这就是只抄参数不看场景的后果。

所以我的建议是：拿到一个需要调优的ES集群，先花一到两天时间把监控搭起来、把基线数据记录下来，再谈改动。把“改配置”当成一次有预期的实验，而不是病急乱投医的偏方。后面每一步调优都要能回答三个问题：改这个参数是为了解决什么现象？为什么它能解决？改完之后怎么验证？

2. 集群与容量规划：分片数、节点角色怎么定

2.1 分片数不是越多越好，也不是越少越好

很多人对分片数量有两个极端理解：要么觉得节点多，分片应该多开，充分利用并发；要么觉得分片越少越好，省内存省开销。这两个都不全对。分片是Lucene索引的切分单元，查询会并行落在多个分片上，然后归并结果。分片太多，协调节点的归并压力大，每个分片还要占用内存和文件句柄；分片太少，单个分片数据量过大，查询和写入都容易触顶。

实务上我一般用“单分片数据量”这个维度来规划。日志场景下，单分片建议控制在30GB到50GB之间。为什么是这个区间？因为单个Lucene段在几十GB级别时，查询性能还能保持线性扩展，超过50GB之后底层索引的扫描成本明显上升；而如果单分片只有几GB，又会造成分片数量过多、资源碎片化。

拿我的场景具体算一下。每天3亿条日志，压缩后每条平均约1KB，日增量约300GB。如果保留7天，总量约2.1TB，加上副本就是4.2TB。按单分片40GB来算，主分片数约为2.1TB / 40GB，也就是54个。分布在6个节点上，每个节点约9个主分片，加上副本就是18个分片。这个密度是合理的。

有人会问：分片数在创建索引时就定了，以后想改怎么办？7.x提供了_split和_shrink接口，可以在线调整，但都比较重，而且要重建索引。所以最好的策略是创建索引之前就把分片数拍死，拍分片数的依据就是未来一年的数据增量，不能只看当前。

2.2 节点角色拆分：把数据节点和协调节点分开

ES节点默认同时承担master、data、ingest等角色，小规模集群确实没必要拆。但一旦集群规模到了写入量大、聚合查询多的阶段，角色混跑就会互相干扰。数据节点既要接收写入、做索引，又要响应查询和聚合，内存和CPU都被抢占。我当时最直观的感受是：一个大的聚合查询打过来，写入的响应时间马上跟着抖。

建议拆成三种角色：

• master节点：只有投票和集群管理职责，不存数据。至少3个，避免脑裂。
• 数据节点：存储数据和执行写入/查询，是主力。
• 协调节点：只接收客户端请求，做路由、分发、聚合结果汇总，不存数据。适合查询量大、聚合多的情况。

在elasticsearch.yml里通过node.roles配置：

# master节点 node.roles: [ master ] # 数据节点 node.roles: [ data ] # 协调节点 node.roles: [ ingest ]

注意，7.x之后不能简单通过node.data: true/false来配置了，统一用node.roles。协调节点不需要存储数据，所以磁盘要求低，但内存和CPU要好。它最大的作用是隔离“查询聚合的CPU开销”，避免查询拖累数据节点上的写入。

我当时加了2个协调节点之后，写入高峰期的抖动明显缓解。道理很简单：原来一个超大聚合查询会在所有数据节点上跑，现在数据节点只负责返回本分片的结果，真正的归并计算发生协调节点上，数据节点的GC压力就降下来了。

2.3 JVM堆内存规划：31GB的来历

ES的堆内存设置是很多人纠结的点。官方建议是不超过物理内存的50%，原因有两条：第一，ES依赖操作系统的Page Cache来缓存磁盘上的索引文件，这部分内存不能被JVM堆占用；第二，JVM在32GB以下可以使用压缩指针技术，超过32GB之后指针膨胀，堆利用率下降，反而更慢。

所以64GB物理内存的机器，堆设到31GB左右就是上限了，剩下的约33GB留给操作系统做文件缓存。32GB的机器，堆设到16GB。我见过有人给ES堆设了40GB，结果GC暂停时间到了秒级，集群直接卡死。这个配置在jvm.options里改：

-Xms31g -Xmx31g

注意-Xms和-Xmx要设置成一样，避免堆动态伸缩带来的性能抖动。改完之后重启节点，可以在日志里确认实际生效的堆大小。

这里多提一句：堆不是越大越好。当堆变大的时候，Full GC的停顿时间也会变长，对在线业务的影响是不可接受的。我自己在数据量增长之后，宁愿加节点、拆索引，也不愿意把单节点堆往上顶。

3. 索引层调优：Mapping、Refresh与段合并的实操细节

3.1 写Mapping的三个取舍

索引层面的调优，收益往往比系统参数更明显。第一步是设计合理的Mapping，这一步很多人忽略，等数据写进去几T之后才发现问题，再想改就只能重建索引，代价极大。

第一个取舍是字段类型。日志场景里，很多字段其实不需要全文搜索，比如日志级别（level）、接口路径（path）、错误码（code）。这些字段如果用text，会被分词器拆成词项，建立倒排索引，既占磁盘又拖慢写入；正确的做法是用keyword。keyword不做分词，适合精确匹配、排序和聚合。我接手之后把一批text改成了keyword，索引体积直接小了约20%，查询也快了。

第二个取舍是doc_values。它和倒排索引是两套结构，doc_values面向列式存储，用于排序和聚合。如果你确定某个字段永远不会参与聚合和排序，可以关掉doc_values来省磁盘。但如果拿不准，就保持默认开启，因为聚合查询如果真的需要它，少了会非常慢。

第三个取舍是关闭动态映射。ES默认遇到新字段会自动创建映射，这看起来方便，实际是灾难温床。日志系统里字段五花八门，一个偶然打进来的对象字段可能被拆成几十个嵌套字段，索引膨胀不说，映射爆炸还会导致写入变慢。我的做法是在索引模板里设置dynamic: false，未知字段丢进_source但不再建立索引。

一个日志场景的Mapping示例：

{ "mappings": { "dynamic": false, "properties": { "level": { "type": "keyword" }, "message": { "type": "text" }, "path": { "type": "keyword" }, "timestamp": { "type": "date" }, "cost_ms": { "type": "integer" } } } }

3.2 Refresh Interval：写入性能提升的立竿见影方法

ES写入的流程是：请求先进内存Buffer，同时写translog，然后每隔一段时间执行一次refresh，把Buffer里的数据转成不可变的段，段中的数据才变成可搜索。默认的refresh_interval是1秒，这是为了“近实时”搜索体验。但对于日志场景，下游很少依赖秒级可见性，把refresh间隔调大，能减少频繁刷新引起的IO和CPU开销。

我当时在写入密集的索引上把刷新间隔改成了30秒，写入吞吐从每秒3.2万提升到5.1万左右，效果立竿见影。配置方式：

PUT my-index/_settings { "index": { "refresh_interval": "30s", "translog.durability": "async", "translog.sync_interval": "5s" } }

这里另一项调整是translog。默认translog.durability是request，也就是每次写入都刷盘，最安全但最慢。改成async之后，批量写入的性能会明显提升，代价是节点宕机时可能丢失最近几秒的数据。对于日志检索这种可容忍少量丢失的场景，这个取舍是划算的；如果是订单、交易类数据，老老实实保持request，别为了性能丢数据。

translog.sync_interval控制异步刷盘间隔，5秒到10秒比较常见。设置太短意义不大，太长会增加丢数据风险窗口。我建议先看业务容忍度再定。

3.3 段合并与磁盘IO的博弈：force_merge的时机

Lucene底层是分段存储的，一个段就是一个不可变的倒排索引集合。refresh会产生大量小段，后台会通过merge合并成大段。段的多少直接影响查询速度：查询需要依次检查每个段，段越多开销越大。同时，段文件占用的内存也更多。但merge本身又是CPU和IO密集操作，如果在业务高峰强行merge，会和正常读写抢资源。

我的策略是：把过期前一天的历史索引设置为只读，然后在凌晨低峰期执行force_merge，把段数合并到1到2个。命令很简单：

POST my-index-2024.11.01/_forcemerge?max_num_segments=1

执行之前先把索引置为只读，否则新写入的数据会产生新的段，合并完等于白干：

PUT my-index-2024.11.01/_settings { "index": { "blocks.write": true } }

force_merge之后的查询性能提升是很直观的。我这边有个索引原来60多个段，查询一个时间范围要一两秒，合并到1个段之后，同样的查询在200毫秒以内。当然了，正在写入的索引不要频繁force_merge，否则一边写一边合，IO根本吃不住。不定时做一次，比天天做效果好得多。

4. 查询性能优化：从一条慢查询说起

4.1 filter和query：评分是性能杀手

查询优化往往比索引优化更容易让人懵圈，因为问题不是单条语句缓慢，而是整个集群被拖慢。有一类典型的慢查询长这样：用query_string做全文检索，把所有条件都塞进去。它的问题在于，query_string走的是评分流程，每个文档都要算相关性分数，而且结果不能被缓存。

ES里查询分两种上下文：query和filter。query上下文会计算评分，filter上下文只做匹配和过滤，不评分，而且filter的结果会进入节点级别的bitset缓存。日志检索场景里，大多数查询根本不需要评分，只需要把符合条件的日志捞出来。把条件从query挪到filter，性能提升极其明显。

我改之前同样的错误日志检索，响应时间大约120毫秒，改成filter之后降到20毫秒左右。关键不是一次查询快了多少，而是filter结果会被缓存，相同范围的多次查询可以直接命中缓存，整个集群的CPU负担都降下来了。

一个推荐的写法：

{ "query": { "bool": { "filter": [ { "term": { "level": "ERROR" } }, { "range": { "timestamp": { "gte": "now-1h" } } } ] } } }

如果你的确需要关键词搜索，确保不要在大范围上做全文检索；全文检索只保留在message字段上，其余条件全部用term、range、term等多路filter。这是最基础也最见效的查询优化。

4.2 深分页：from+size的坑，scroll和search_after怎么选

深分页是日志系统的老大难。from + size看起来简单，但ES的默认执行方式是：每个分片先取from + size条结果，协调节点把所有分片结果全部归并排序，最后再截取from之后的size条。这意味着翻到第1万页时，每个分片都要把前面一万多条全捞出来，资源开销是指数级增长的。ES默认限制max_result_window是10000，超过就报错。

深分页有三个替代方案，各有适用场景：

我这边日常查询都改成了search_after + PIT。先创建PIT：

POST my-index/_pit?keep_alive=5m

返回一个PIT ID，查询时带上：

{ "size": 100, "sort": [ { "timestamp": "asc" }, { "_id": "asc" } ], "pit": { "id": "PIT_ID_xxx", "keep_alive": "5m" }, "query": { // 你的filter条件 } }

第一页结果里取出最后一条的排序值，第二页通过search_after传入：

{ "size": 100, "sort": [ { "timestamp": "asc" }, { "_id": "asc" } ], "search_after": [ "2024-11-01T12:34:56.789Z", "abc123" ], "pit": { "id": "PIT_ID_xxx", "keep_alive": "5m" } }

这套方式把深分页的代价从O(n)降到了O(page_size)，在页面上翻两三万条日志也不会让集群卡死。

4.3 聚合优化：避免超大基数聚合

日志场景里聚合查询很常见，比如“过去24小时每分钟的错误数趋势”“接口响应时间分布”。聚合慢的根本原因是桶数量太多：在分片层面做局部聚合，把结果汇总到协调节点再合并，如果时间范围大、粒度细，桶的数量会达到百万级别，内存直接吃满。

我遇到过一个真实事故：业务方跑了一个按分钟聚合一周时间范围数据的查询，直接导致协调节点OOM，整个集群瘫痪了几分钟。从那以后我把聚合查询的管控做了三件事。

第一，时间范围必须和粒度匹配。按分钟聚合，时间范围就不要超过24小时；按小时聚合，最多看30天。在聚合里加上hard_bounds限制桶数量：

{ "size": 0, "aggs": { "errors_per_minute": { "date_histogram": { "field": "timestamp", "fixed_interval": "1m", "hard_bounds": { "min": "2024-11-01T00:00:00Z", "max": "2024-11-01T23:59:59Z" } } } } }

第二，聚合的基数要有上限。如果你的日志里某个字段的基数特别大，比如接口路径有几百万个，做terms聚合就会很危险。解决办法是尽量用精确度较高的近似聚合，或者通过前置filter缩小文档集。

第三，把size和shard_size配合调好。先说shard_size：ES聚合是先在每个分片上取shard_size个桶，再在协调节点做归并，最后返回size个桶。如果shard_size太小，各分片Top桶偏差大；太大则传输量大。通常shard_size = size * 10 + 10是合理的起点。挖掘完了可以再调。

5. 系统层参数与压测复盘：哪些参数值得改，哪些是玄学

5.1 文件描述符、交换区和锁定内存

到了系统层之后，需要调整的参数其实不多，但每一样都影响稳定性。很多人从网上抄了一大段sysctl参数，里面的确有些是必要的，有些则属于锦上添花。我建议按优先级来调。

首先是文件描述符。ES对并发连接和文件句柄的消耗非常大，Linux默认的1024远远不够，高并发下会报Too many open files。调整方式：

ulimit -n 655360

或者写入/etc/security/limits.conf让配置持久化。我这边直接设成了655360，再没有出现过句柄耗尽的问题。

其次是vm.max_map_count。ES会创建大量内存映射文件，默认值65530经常不够，启动时会报“max virtual memory areas vm.max_map_count [...] is too low”。设成262144是常规操作：

sudo sysctl -w vm.max_map_count=262144

再者是内存锁定。ES里有个配置项bootstrap.memory_lock，建议设置成true，同时在系统层面关掉swap。原因很简单：如果JVM的部分内存被换到磁盘上，GC耗时和查询延迟会急剧恶化。开启方式是在elasticsearch.yml里加：

bootstrap.memory_lock: true

可以通过日志确认是否锁定成功，如果没锁上会有warning。启动后还可以用命令验证，确保mlockall不为0。

最后，ES自带的discovery和gateway.recover_after_nodes等参数在集群重启时也有影响，但对在线性能影响没有前面几个大。我建议先从能直接改善CPU、IO、GC的点入手，不要一上来追求全套配置。

5.2 我的一次压测复盘：从70秒到3秒经历了什么

理论讲了一堆，真正让团队信服的还是压测数据。我把自己做的一轮调优过程完整复盘一下，帮你串起前面所有的内容。

当时做了一轮三天左右的调优，每一轮只动一个变量，用脚本记录前后对比。压测用的工具是自写的Go脚本，向集群持续灌日志并模拟查询，监控指标由Prometheus采集。

第一阶段只调写入，不改查询，所以查询P99改善有限；第二阶段做完查询优化后，瓶颈从查询转到了磁盘IO；第三阶段的重规划和force_merge把磁盘扫描量降下来，整个系统才算稳了。三个阶段对应了三种不同的瓶颈，如果上来就一股脑改完，你根本不知道是哪一步起的作用。

压测时要注意一个问题：清洗环境。每次改变配置后，最好在压测前先把旧的查询缓存清掉再跑，不然结果会被缓存污染。可以通过重启节点或者调用缓存清理接口来处理，保证测试数据的可信度。

5.3 常见问题速查表

最后整理一份问题排查表，都是我在实际维护中反复遇到的典型情况，你可以直接当速查手册用。

这些问题的共同点在于：单一现象往往对应多个潜在原因，不要只看表面。就拿“查询突然变慢”来说，有可能是段太多、缓存被大查询挤掉了、也可能是GC停顿导致的偶发延迟。我的习惯是先看GC日志，再查segment数量，最后才翻查询缓存命中率，按顺序一步步排除。

最后说一点个人体会。Elasticsearch调优没有银弹，别人的参数表抄过来大概率不顶用。我在踩了无数坑之后，养成了一个习惯：每次调优只动一个变量，记录改动前后的监控数据，对比后再决定下一步。这个方法比任何参数都重要，因为ES的参数太多了，环境差异太大了，只有你自己的数据最有说服力。如果你正准备开始调优，不妨从搭监控、记录基线开始，那就是通往性能优化最快的一条路。