接手一个用了快两年的Elasticsearch集群查询从最初的毫秒级退化到两三秒bulk写入时不时报429队列满这个场景在不少团队里都真实发生过。我当时第一反应是加节点、加内存后来翻了一圈配置和日志才发现问题出在分片粒度和mapping设计上加硬件纯属浪费钱。Elasticsearch性能调优这件事最大的难点在于大多数人从一开始就不了解它的工作机制数据写入后到底发生了什么查询为什么有时候快有时候慢分片数量到底怎么规划这些问题不解决调参永远是碰运气。这篇内容适合刚接触ES但已经被慢查询和写入堆积折磨过的人也适合那些集群已经上线、现在每天在监控大盘上看一堆红色指标的运维和开发。我会从Lucene的底子讲起一路拆到分片规划、mapping设计、查询写法、写入链路和JVM内存最后给出一套我自己在实战里反复用的排查SOP。核心思路一句话性能调优不是调一个参数而是理解数据在每个环节怎么流动然后找到那个最紧的瓶颈。1. 先摸清性能问题的源头ES写入与查询的两条核心链路1.1 数据最终落到哪段与倒排索引很多人用ES脑子里想的是我在MySQL里插一行在ES里也插一行这个模型从第一天起就是错的。ES的底层是LuceneLucene里没有行的概念只有段segment和倒排索引。一个分片shard就是一个独立的Lucene索引它由很多段组成。每个段是一个完整的小索引内部包含倒排表、词典、doc values等结构。倒排索引做的事好比书末尾的关键词索引从词出发查到页码也就是从term找到包含它的文档ID列表。你搜性能调优ES不是扫描所有文档去匹配而是在词典里定位这个词然后直接拿到对应的文档ID列表。这就是ES能快速出结果的根本原因也是它和MySQL在检索机制上最本质的差别。段的最大特点是不可变一旦写进磁盘段就再也改不了。这个设计看着笨其实非常聪明——不可变意味着可以安全地被缓存、被操作系统页缓存命中也不需要处理复杂的锁竞争。但代价是更新和删除都只能做标记不能真正清理新数据永远要生成新的段。理解不可变这三个字后面很多调优逻辑都能串起来比如为什么需要段合并为什么force merge对查询提升那么大。1.2 写入路径refresh、translog、flush三兄弟ES写入一个文档流程是这样的请求先到协调节点按routing算法找到主分片写进Lucene的缓冲区。注意这时候数据还在内存里是看不见的必须等refresh才会暴露给搜索。refresh默认每秒跑一次把缓冲区里的数据生成一个新的小段使它可以被搜索。这就是ES近实时说法的来源也是为什么你刚写入就立刻去查询偶尔会查不到数据——尤其是用了标准同步写法却忘了刷新确认的场景。translog则是一个写前日志。每笔写请求在进内存缓冲区的同时会追加到translog里这样即使节点宕机也能从translog恢复还没flush到磁盘的数据。flush则是把缓冲区数据落盘并清空translog。flush的触发条件是translog大小超过512MB或时间超过30分钟两者默认取先到者。从这个链路能得出一个非常实用的推论如果业务允许查询看到数据有几十秒延迟把refresh_interval调大到30秒写入吞吐提升会非常明显。数据攒在缓冲区里一次refresh生成更大的段IO压力也小很多。后面写写入侧调优再细说。1.3 查询路径query和fetch到底在干什么一次搜索请求到协调节点后会被分发到索引的所有分片上或指定分片。每个分片在自己的段里执行查询返回一个得分文档ID的排序结果——注意这一步不返回完整文档。协调节点汇总各分片返回的top N列表做全局排序算出最终top N。然后进入fetch阶段协调节点拿着这些文档ID去对应分片取完整文档组装后返回给客户端。这解释了为什么深分页的代价极大页码越深所有分片都要参与排序和计算还要把中间结果在网络上搬一遍。page 1和page 10000的唯一区别只是全局排序后丢弃的内容更多计算和网络开销几乎一样。所以生产环境要少用fromsize深分页转用search_after是必然选择。这两个阶段任何一步出问题都会表现为查询变慢。但慢在哪一步需要靠核心指标来分辨。我建议每个ES监控面板上至少要同时展示query阶段和fetch阶段两条耗时曲线多数人能更快定位问题query慢多半是分片上有大聚合或复杂条件fetch慢多半是返回字段太多或者单文档过大。2. 分片与副本的地基工程数据布局决定集群上限2.1 每个分片多大才算健康分片是ES的最小工作单元所有读写都发生在一个个分片上。分片太大或太小都影响性能。社区给的经验区间是20GB到50GB上下这个区间背后是有道理的。分片太小比如小于10GB单分片数据少查询会分散到大量分片上协调节点汇总的开销变大分片太大比如超过100GB单个分片内段数量多、大段合并压力大故障恢复也慢——恢复分片需要拷贝全部数据分片越大恢复时间越长。我在实践里遵循一个更细的口诀业务查询频繁的索引分片控制在30GB以内日志类按时间分索引的单分片跑到40GB-50GB再考虑滚动。关键词是上限不要卡下限。数据总量连20GB都不到的索引给1个主分片就够别为了分片多点提升并发去堆一堆空分片。空分片也要占文件句柄和线程池资源反而拖慢整体。2.2 分片数量规划计算方法和场景对照分片数量有一个粗略公式分片数 数据总量 / 目标分片大小。假设未来半年索引数据总量大概2TB目标每个分片40GB那就需要约50个主分片。但还要考虑节点数量和总分片上限。官方建议每GB堆内存对应不超过20到30个分片。一个更稳的健康线是集群总分片数 节点数 × 每节点分片上限比如20个。例如3个数据节点、每个节点堆内存8GB那总分片控制在60到70个以内比较稳妥。我踩过一个印象很深的坑某个客户按天建索引但没配滚动策略跑了半年单个分片到了600GB。查询不慢才怪。后来改成按天滚动索引、每个分片控制在30GB左右相同硬件下p99查询时间从4秒降到400毫秒——这不是什么魔法只是让数据分散到了更合理的工作单元里。索引模板和rollover组合使用是日志类场景的标准姿势模板定义好分片数、副本数、mapping、分词器每天或每几天自动滚动到新索引。这两件事一定要在集群上线前配好临时补配的代价比想象中高得多。2.3 副本的定位高可用和查询吞吐的杠杆副本的作用经常被误解为备份。副本确实是冗余但更重要的价值是水平扩展查询能力查询可以命中任一副本副本越多单分片上的查询并发能力越强。默认一个主分片配一个副本。如果查询压力大可以临时把副本跳到2个查询吞吐会明显上升。但副本不是白给的每多一个副本磁盘占用和写入放大都翻倍写请求的IO、带宽、CPU都要额外处理副本同步。所以只读型报表场景可以多加副本高写入场景副本宁缺毋滥。另外一个容易忽略的点副本数可以随时动态调整但主分片数不行。创建索引时就要认真规划主分片数量一旦建立只能通过重建索引或拆索引的方式修改。主分片规划要做在前面副本可以上线后按需加。2.4 时间序列索引的rollover实操对于日志类数据最省心的方案是按天建索引配一个rollover策略。rollover会自动判断当前索引是否达到某个条件分片大小、文档数、时间然后创建新索引并切换别名老索引后续可以冻结或删除。实际配置里我通常这样分单索引大小超过30GB或文档数达到5000万就先滚动。注意rollover是对别名生效的需要先建索引模板再给模板匹配的索引挂一个别名。写入请求始终写别名查询也走别名后面滚动索引时应用完全不用改。这里再补一个提醒索引模板里一定写上分片数的上限约束防止生产环境误创建大量分片把集群压垮。我见过不止一次因为模板没限制一晚上创建了几千个分片集群直接变红的案例。模板里的index.routing.allocation.total_shards_per_node这个参数上线前一定要配好。3. Mapping与分词器动手建索引前必须做的三步检查3.1 字段类型选错的代价远比你想的大Mapping是ES理解字段的依据也是性能问题的隐藏地雷。最常见的错误是把应该用keyword的字段设成了text结果所有精确匹配和聚合都变成了全文匹配和分词又慢结果又不对。比如订单状态字段status值是paidunpaid如果用text类型精确匹配会查不到聚合也会因为分词结果不对而出错。正确做法是用keyword让ES按完整字符串做精确匹配和聚合。IP、订单号、手机号这类字段同理一律用keyword。如果业务里有范围查询需求的数值字段价格、金额、时间戳用integer/long/double不要都塞成keywordkeyword上的范围查询效率很糟糕。我的建议是建索引前把业务字段表完整过一遍对每个字段回答三个问题——需不需要全文搜索、需不需要排序聚合、需不需要范围查询。这个流程能提前挡住90%的mapping坑。大部分线上事故拆开看都是当初图省事没细化字段类型。3.2 分词器的选择和搜索需求匹配分词器直接决定检索质量和查询性能。中文场景里最常见的问题默认的standard分词对中文是按单字切分的性能调优会被切成性能调优四个字。做中文产品搜索的话这种切法召回率高但噪声大准确性差最后为了弥补就写一堆复杂的组合查询性能自然掉下来。生产上我推荐IK分词器的ik_smart或ik_max_word或者根据业务词典定制。但要注意IK词典一旦更新是需要全量重建索引才能生效的所以词典维护要放在独立流程里。如果业务只需要精确搜索用户输入什么就匹配什么甚至可以让字段保持keyword不分词性能最好语义也最稳。还有一个容易被忽视的点analyzer在写入和查询两个环节都会起作用。如果对同一个字段在写入和查询时用了不同分词器建议在query_string查询里明确指定analyzer或search_analyzer避免两边分词不一致导致查不到数据。3.3 关掉用不到的功能index、doc_values、fielddata很多默认行为我们根本用不到却在白白消耗存储和CPU。控制的关键是三个开关index这个字段是否需要被搜索。只想存而不搜的字段比如内部备注、原始报文设置为false查询阶段的开销和索引体积都会下降。doc_values是否需要排序和聚合。所有keyword和数值字段默认开启doc_values这是列式存储结构。如果不排序不聚合关掉它能节省相当可观的磁盘空间。fielddatatext字段的聚合必须用fielddata代价是吞堆内存能不开就不开。如果需要聚合建议在mapping里加一个keyword子字段在keyword副本上聚合。另外要警惕mapping爆炸开启动态映射会让字段数失控某些业务文档来什么字段就自动加什么一个索引积累到几万个字段每次查询都要扫描字段元数据CPU和内存都会被拖垮。生产环境务必用动态模板配合strict动态映射或者把index.mapping.total_fields.limit设成合理值。我一般设置2000超过就报错逼着上游规范化文档结构。4. 查询侧调优实战让慢查询现形并找到根因4.1 先开慢查询日志别凭感觉猜调优的第一个动作不是改代码而是拿到证据。ES自带慢查询日志区分搜索慢日志和索引慢日志配置在索引模板或具体索引上。例如index.search.slowlog.threshold.query.warn: 2s index.search.slowlog.threshold.query.info: 500ms index.search.slowlog.threshold.fetch.warn: 1s index.search.slowlog.threshold.fetch.info: 200ms index.search.slowlog.level: warn配置后超过阈值的查询会打印在ES日志文件里附上完整DSL。拿到DSL你才能知道是哪个客户端的哪个操作在拖后腿。我强烈建议慢查询阈值别默认沿用官方2秒warn。等它报问题时集群已经很难受了。我推荐query阈值info设500ms、warn设1s让慢查询在成为事故之前就暴露在日志里。同时要配合hot_threads接口排查。节点CPU飙高时执行GET _nodes/hot_threads看ES当前正在执行什么任务一抓一个准。慢查询日志、hot_threads、节点监控三项证据拼在一起基本能完整还原慢查询现场。4.2 query和filter的区别让过滤条件走缓存ES里的查询上下文分两种query context和filter context。凡是带评分的条件——比如match、query_string都会计入相关性打分ES要为每个文档计算得分并排序开销大。而filter context下的条件——比如term、range、exists是不打分的只做布尔过滤而且结果会被缓存相同filter条件的第二次执行几乎零成本。实战原则很简单凡是逻辑上只需要是或不是的过滤条件一律放到filter上下文。范围条件、状态条件、时间范围都应该放在filter里。只有确实需要相关性排序的关键词匹配才放在query里。一条典型的优化写法把原来bool查询里混在一起的match、range、term拆开range和term改放filter数组查询响应时间普遍能下降二三成而且相同条件第二次查询基本是毫秒级因为filter cache命中了。实现上要注意filter条件放在bool下的filter数组里不是query数组。很多人不知道这个区别把所有条件堆在must里性能白白浪费。4.3 深分页为什么慢从第10页开始就该换方案前面讲过fromsize深分页需要在所有分片做全局排序。实际案例里from10000, size10的查询常常比第一页慢几十倍。如果产品只展示前10页后端要加保护措施限制最大from值index.max_result_window默认10000建议按业务设为5000或更少防止有人提交一个from100000的大查询拖垮节点。翻页需求用search_after传入上一页最后一条的排序值ES从下一条继续取不会累积计算被丢弃的文档。大批量导出用Scroll或PIT但那只适合导出场景不适合交互式UI。我经常把这件事讲给前端产品听让用户从第11页跳到第500页既不现实也没必要。产品设计上控制在首页、上一页、下一页就可以了。技术方案要和产品方案一起做单靠后端硬扛最后一定是慢查询日志里的常客。4.4 聚合性能的常见坑和预聚合思路用ES做实时报表发现聚合一上来CPU就飙原因通常是在一大堆text字段上做terms聚合。前面说过text字段聚合默认会报错或被迫走fielddata绕过去就是高CPU操作。另一种情况是聚合基数太大——比如对几千万个唯一值做terms结果集巨大且耗内存。这时候考虑几种方案用composite聚合配合分页拉数据替代一次性terms聚合拉几百万桶。在聚合里设置min_doc_count过滤低频值用shard_size限制分片返回桶数减少跨节点传输量。数据预聚合报表场景下把明细数据按维度预先汇总成指标查询时直接对指标聚合。这是真正的性能杀器而不是依赖ES硬算。实测一个例子一个订单明细索引有一亿文档直接terms按商品聚合需要3秒预聚合之后按商品分组存好查询变成300毫秒集群CPU从70%降到10%。预聚合不是ES的冷门技巧而是报表系统设计的常规思路数据量越大收益越明显。5. 写入侧调优批量、refresh与段合并的三方平衡5.1 bulk写入的正确与错误用法写入性能的第一选择永远是批量接口。但批量不是把小请求简单拼在一起就完事有几个细节影响很大请求大小单次bulk建议5MB到15MB之间文档条数可以从500到5000不等跟单条文档大小相关。超过15MB容易让协调节点内存吃紧太小则批效果不明显。并发数不是越大越好。并发太高会把bulk线程池打满触发es_rejected_execution_exception。一般建议从5开始观察CPU和线程池队列逐步上调找到不报429的最大并发。重试逻辑客户端要带指数退避重试而不是失败就丢弃。Logstash默认带重试自己写写入程序时一定要实现类似逻辑。调这个参数有一个可复现的方法固定bulk大小逐步加并发观察bulk平均耗时曲线。如果耗时稳定说明还没到上限曲线开始上扬说明涌入太快要么降并发要么扩容。5.2 refresh_interval是吞吐和实时性的天平默认refresh每1秒一次换来的是近实时可见性但代价是每秒都要生成一个小段。小段多了段合并压力大每次refresh也占用IO和CPU。如果业务对搜索实时性要求不高——比如日志分析、报表数据允许几十秒延迟把refresh_interval调大{ index: { refresh_interval: 30s } }我见过一个数据接入场景把refresh从1s调到30s后同样机器写入吞吐提升了接近3倍。代价是查询能看到数据的时间最多延迟30秒日志分析场景完全能接受。批量导入历史数据时甚至可以设置成-1禁用refresh导完再调回来。这里有一个必须注意的细节把refresh_interval设成-1之后数据会一直攒在缓冲区和translog里导入结束后一定要手动执行一次POST 索引/_refresh再调回正常值否则后续查询会一直等数据。5.3 段合并策略理解merge调度控制段数量段数量是写入和查询性能的关键指标。段太多查询要打开大量文件、合并大量结果段合并太频繁IO又会飙升。Lucene后台有一个merge线程负责合并小段主要参数index.merge.scheduler.max_thread_count默认是Math.min(3, CPU核数/2)。机械硬盘上建议调成1防止合并抢占IOSSD上可以保持默认或再低一些。index.merge.policy.segments_per_tier默认10决定分层合并的设置。调小会让段更规整但合并更频繁调大段数会多、合并减少。force merge不再写入的历史索引可以做一次_forcemerge把大量段合并成1个段查询性能提升极其明显。我的标准操作流程是每天索引到凌晨跑一次force merge把当天索引的段合并成1到2个段。实测同样查询合并前p99是800ms合并后200ms——原因在于文件打开数量和随机读都大幅减少。但注意force merge只对只读索引安全。还在写入的热索引别做否则一边写一边合并IO会打架。冷数据是段合并最大的收益来源这也是日志类集群要按时间滚动索引的原因之一——老索引可以放心地force merge和删除。6. JVM内存与GC给Elasticsearch做一场运行时体检6.1 heap大小为什么建议不要超过32GBES的JVM堆内存存的是节点状态、缓存和部分查询中间结果跟Lucene使用的磁盘和页缓存是两个体系。官方建议堆内存设为物理内存的一半左右但上限建议控制在30GB或31GB因为Java的指针压缩Compressed Oops只在堆不超过32GB时生效。超过32GB后对象引用变大内存利用率下降GC压力也变大。更重要的是堆外的OS page cache对查询性能影响极大。Lucene的段文件是走操作系统的页缓存读取的很多所谓命中缓存的查询实际是OS页缓存命中了磁盘数据而页缓存不占JVM堆。如果堆给得太多、页缓存就少了整体查询反而变慢。我踩过一个反直觉的典型问题一台64GB内存的机器堆设了48GB查询慢得离谱。把堆降到30GB其余内存留给OS缓存后反而快了。这个方向很多人不信但实际验证非常有效。6.2 从GC日志判断是否需要调参GC调优不是调一堆JVM参数让GC次数变少而是先看GC停顿是否影响业务。多数场景下ES默认GC参数已经够用问题往往出在堆外的内存压力上。怎么看GC打开ES的GC日志默认在logs/gc.log重点观察几个信号年轻代GC频率每秒一次以上说明对象分配太频繁。Full GC一旦出现代表堆接近满了ES会大量挪动数据甚至停止写入。此时最有效的动作不是调JVM参数而是降低堆内缓存大小、减少fielddata、减少深分页和超大聚合。老年代持续增长很可能是缓存了过多filter cache或查询上下文需要排查是不是有人把大结果集放在query上下文里反复执行。一个常见的误操作是看到full GC就去加Xms和Xmx。但如果堆里塞满了大数据聚合的中间结果加内存只是推迟下一次full GC并不能解决根本问题。6.3 真正吃掉堆内存的其实只有几样东西堆内存被大量消耗的通常不是数据本身而是下面几类filter cache和request cache重复的宽范围filter查询会被缓存数量失控就吃堆。聚合中间结果超大桶的terms聚合会把大量命中项堆在内存里特别是shard_size设置过大时。深分页的排序队列fromsize越大协调节点需要把所有分片的结果放进内存做全局排序这是堆内存的大户。fielddatatext字段聚合一旦开启必吃堆内存。排查方法GET _nodes/stats/indices?pretty看各索引的fielddata和query_cache大小GET _cat/thread_pool看线程池队列是否堆积。定位到具体索引和查询后按前面几节的方案处理。我自己的经验法则是老年代使用率达到80%以上并出现Full GC时先别急着加内存查一下最近上线的报表或导出任务大概率是某个大查询或者某个索引的mapping出了问题。这个排查思路用了几次每次都快速找到了明显的罪魁祸首。满堆往往不代表内存不够而是代表某一个查询写歪了。7. 最后一套可落地的调优SOP和我的个人经验7.1 我常用的8步排查顺序在收尾之前我把实战里一直用的排查顺序列出来你照着走基本不会漏先看集群健康status颜色、未分配分片、pending tasks、磁盘水位线。看节点CPU和磁盘IO定位问题节点。开慢查询日志抓到慢DSL。分析慢DSL类型是query慢还是fetch慢是聚合慢还是深分页。检查对应索引的mapping和分片分布。检查GC日志和堆内存指标。按优先级优化mapping问题最优先分片布局次之然后查询写法最后才是JVM参数和加机器。每次只改一个参数压测对比记录变化。这八步看起来平淡但我绝大多数线上问题都在这几个环节找到了答案。调优最大的坑是一次性改了很多参数最后根本分不清是哪个调整起了作用。所以即便你很着急也要一次只动一个变量让结果可归因。7.2 建集群第一天就该做的事最后想聊一个容易被忽略的事实很多性能问题是集群上线第一天埋下的雷。等变慢再去调重建索引、重新规划分片代价非常大。所以如果你现在还处于搭建阶段请一定提前做这几件事根据数据增长规划主分片数和索引模板把模板写进配置而不是临到用再建。把mapping当成接口设计来做字段类型、是否索引、是否doc_values在上线前敲定。从第一天就开启慢查询日志设置合理的阈值让监控证据从一开始就有积累。设定磁盘水位线low建议85%、high建议90%避免磁盘写满触发只读保护。定期做容量规划别等磁盘满了再临时加节点。容量规划不是算一次就完数据增长曲线变化后要重算。7.3 关于加机器的最后一句所谓性能调优一大半的工作是让数据分布和查询设计合理少部分是参数调整只有很小一部分才是堆硬件。很多人一慢就想加内存加机器但这相当于水管堵了不去找堵塞点拼命加压力。我见过太多集群加了一倍机器慢查询依旧慢——因为瓶颈根本不在节点数量上。如果你只能记住三句话我建议是分片大小控制在20到50GB别让一个分片变成大象腿。所有过滤条件放filter上下文别让评分计算偷走你的CPU。批量导入时关refresh历史索引定期force merge。这三招不会让ES变成搜索引擎神器但足以让一个还能用但很痛苦的集群恢复健康。剩下的就是拿着监控数据一条一条去验证和排查。调优这条路没有终点但只要你把每个参数、每个查询的收益和代价都记录清楚每一次调优都会变成下一次排查的底牌集群会越跑越稳。