做Elasticsearch的人十有八九都被内存问题折磨过。节点动不动OOM、GC几十秒、查询突然变慢打开监控一看堆内存飙到90%以上很多人第一反应就是加内存、加节点。我刚接触ES那会儿也干过这种事结果堆从16G加到30GFull GC反而更频繁写入吞吐直接腰斩。后来把JVM内存模型、Lucene的堆外索引机制、circuit breaker熔断器一层层拆开看才把ES这套内存体系真正串起来。这篇内容就以“Elasticsearch内存模型调优”为主线把“性能瓶颈”的定位方法、参数计算和实战排障完整讲一遍适合集群高峰就GC抖动的、经常OOM的、或者想系统搞懂ES内存机制的开发和运维同学。我尽量用大白话加上实操命令把每个决策背后的“为什么”也讲清楚。毕竟网上ES调优的文章一搜一大把但大多是参数堆砌真正告诉你什么时候该动哪个参数、动了之后怎么验证的还真不多。1. 先把内存模型拆开ES的堆内、堆外和断路器1.1 堆内到底堆了些什么ES的堆内内存并不是用来存文档原文的。文档数据落盘后由Lucene管理绝大部分索引文件通过mmap映射到进程地址空间走的是堆外内存。JVM堆里放的主要是Lucene索引结构中的一部分核心数据结构、查询上下文以及各种缓存。具体来说堆内的主要“住户”有这些fielddata缓存做排序、聚合、脚本时ES需要把倒排索引里的字段值倒腾到堆内成为列式结构这部分缓存是堆内存的一大消耗点而且默认不设上限。node query cache也叫filter cache缓存过滤查询的结果默认占堆内存的10%。shard request cache缓存分片级聚合结果默认关闭一旦开启没有明确上限。bulk和search请求的临时对象大批量写入时构建索引的临时结构、深分页请求的上下文也会在堆里占不少空间。mapping、集群状态和内部任务字段映射越多集群状态越大这块内存同样水涨船高。很多人有一个误区堆配得越大越好。实际上堆越大GC扫描的区域就越大尤其在Old区接近满时Full GC的停顿时间会肉眼可见地飙升。用8GB堆跑几千万文档的集群不少见数据量大到必须上30GB堆的话更应该做容量规划和分片设计而不是无脑加堆。记住一个原则ES的堆是“精打细算的工作台”不是你放所有数据的仓库。1.2 堆外内存Lucene和OS Page Cache才是性能主力很多人不知道ES真正查询时大部分时间都在跟操作系统的Page Cache打交道。Lucene把索引文件通过mmap映射到进程地址空间后读取索引数据走的是内核Page Cache这部分内存是堆外分配的不归JVM管。这就是为什么ES的内存规划里永远要留出一半左右的物理内存给OS当Page Cache。一个filter查询如果命中了Page Cache响应时间通常在毫秒级如果索引文件被换出到磁盘光随机IO的寻道延迟就要几十毫秒这还是乐观情况。换句话说堆内分配太多挤压了Page Cache的空间等于把ES最值钱的高速通道给占了。我踩过一个典型坑某次把64GB机器上的JVM堆调到了48GB理论上堆内存宽裕了结果查询P99从20ms恶化到120ms。原因就是Page Cache被压缩到16GB以下冷数据频繁落盘。后来把堆调回30GBP99立刻恢复。调优ES内存眼光不能只盯着JVM堆堆外的Page Cache同样是性能瓶颈的命脉。1.3 Circuit Breaker保护堆的最后一道闸门JVM的OOM代价极大Full GC都救不回来时整个节点直接挂掉。为避免这种事ES给堆内内存设置了多级熔断器Circuit Breaker请求所需内存一旦超出阈值直接拒绝而不是硬扛。几个核心熔断参数参数默认值作用indices.breaker.total.limit95%所有熔断器合计不超过堆的百分比indices.breaker.fielddata.limit60%fielddata加载数据时触发熔断indices.breaker.request.limit60%请求构造结果集时的内存估算indices.breaker.inflight_requests.limit100%HTTP请求层的内存保护默认等同于total这里要强调一个认知熔断器是基于“预估内存”做判断不是精确计算。ES会在请求执行前估算要分配多少内存如果超过阈值直接抛CircuitBreakingException。所以线上看到data too large异常并不意味着堆真的满了可能只是单个请求的内存预估值太大。后面第5章我会写怎么区分“真的OOM”和“被熔断误伤”。2. 三条金标准堆大小、swap、GC选型2.1 堆上限30GB压缩指针的临界点JVM在堆小于32GB时会启用CompressedOops技术对象引用从8字节压缩到4字节。这意味着相同的数据量小堆反而能装下更多对象。但当堆超过32GB后压缩指针失效所有引用膨胀回8字节每多分配一点堆实际能使用的有效空间反而在缩水。官方建议和业界实践都把30GB当作一个经验红线。这背后有个简单的计算逻辑30GB堆配合4字节指针理论上引用占用的空间大约是堆总大小的八分之一左右超过32GB后引用开销翻倍堆越大这种浪费越明显。所以如果物理内存很大比如有128GB优先拆成两台64GB的节点每台堆给30GB比单台128GB节点堆给100GB要健康得多。我在实践中还发现一个细节如果非要把堆配到32GB以上干脆直接跨过40GB让可用空间的增长抵消指针膨胀的损耗。但从ES生态和故障域隔离的角度看我仍然建议通过增加节点而不是扩大单节点堆来解决容量问题。2.2 内存对半分给OS Page Cache留口饭官方文档和大量社区实践都指向同一个经验值节点物理内存的一半分给JVM堆最高不超过30GB另一半留给操作系统Page Cache和Lucene内部使用。以64GB内存的机器为例堆给30GB或31GB纯洁癖可以给30g稳妥剩余的内存给Page Cache。这个比例的背后逻辑就是1.2节说的堆和数据缓存是跷跷板堆占得太多Page Cache就得挨饿查询延迟和吞吐立刻变脸。同时还要处理swap的问题。一旦操作系统的swap介入JVM堆被换到磁盘GC停顿时间会从毫秒级跳到秒级这是线上事故级别的抖动。必须在elasticsearch.yml里开启bootstrap.memory_lock: true开启后ES会自动尝试锁定堆内存。如果启动报错多半是操作系统限制没放开需要调整/etc/security/limits.conf里的memlock配置es soft memlock unlimited es hard memlock unlimited容器环境要注意memory_lock在Docker/K8s里依赖权限配置通常是CAP_IPC_LOCK或--ulimit memlock-1:-1。2.3 GC选型CMS还是G1别再纠结了ES的不同版本对GC的默认选用一直在变。ES 7.16之前官方默认使用CMS7.16之后切换到G1并持续到8.x。如果你的ES版本是7.16及以上默认G1就对了不用费劲去切换CMS如果是7.16以下的老版本建议评估升级后使用G1。G1最大的优势是Region化内存布局和可预测的停顿时间。它把堆分成多个Region不需要像CMS那样发生全局扫描能用-XX:MaxGCPauseMillis控制单次GC停顿目标。适用条件是堆较大、对象更新频率高的场景恰恰匹配ES的常规运作模式。在jvm.options里我通常这样配置-Xms30g -Xmx30g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize16m -XX:InitiatingHeapOccupancyPercent30三个关键点Xms和Xmx必须设成一样的值避免堆动态扩容引起内存抖动这个看起来是常识但生产环境的坑从来不嫌多。InitiatingHeapOccupancyPercent默认是45意思是老年代占用到45%时G1开始启动并发标记。在ES场景里我习惯调低到30让G1早点介入避免老年代堆积后触发Full GC。MaxGCPauseMillis不要往小了乱压过小的目标会导致G1频繁做GC吞吐量下降。200ms是一个比较现实的起点压测后再调整。我见过有人把CMS参数和G1参数混在一起写在jvm.options里这会让JVM不知所措。配置GC关键前提是搞清楚自己用的JDK版本和ES版本对应的默认GC再去选参数不要惯性照搬网上的老文章。3. 性能瓶颈定位实操3.1 现象盘点到底是不是内存的锅先泼一盆冷水很多“内存问题”其实根源不在内存。我遇到过明明是shard规划不合理导致查询变慢运维却怀疑是堆不够打算加内存的也遇到过因为磁盘IO瓶颈导致bulk堆积结果误判成堆内存溢出的。所以动手调优之前先做诊断别上来就改参数。按我自己的排查习惯会把现象分为四类现象可能原因优先排查项节点CPU高、GC时间飙升堆内缓存过大、查询过重GC日志、_nodes/stats/jvmbulk写入失败、拒绝队列占满、熔断触发_cat/thread_pool、熔断日志查询延迟波动大Page Cache命中率低、磁盘IO_cat/nodes、OS指标节点直接OOM退出堆内对象溢出、fielddata失控OOM dump、GC日志看ES的监控面板时重点关注heap.percent和ram.percent两个指标。前者是JVM堆使用率后者是节点物理内存使用率。如果heap.percent不高但ram.percent常年在95%以上说明Page Cache被吃光了问题在堆外——很可能有别的进程占用内存或者你堆外内存规划失误这时候加堆只会更糟。3.2 jstat、jmap、arthas现场取证确认和内存相关之后赶紧上JVM工具链做现场取证。第一步用jstat观察GC趋势jstat -gcutil pid 1000这条命令每秒钟打印一次各代内存使用率和GC次数。重点看E区年轻代是不是迅速打满、O区老年代增长斜率是不是太陡、FGC列的数字是不是在涨。如果老年代增长极快且FGC已经反复出现基本可以判断堆内装不下了。第二步用jmap看堆里到底什么对象占大头jmap -histo pid | head -30如果排在前面的全是被查询返回的POJO、桶聚合产生的对象那问题出在查询层如果全是[C、[B这类字符/字节数组可能是文档内容被大量加载到堆里了。第三步需要深挖时抓堆转储jmap -dump:live,formatb,file/tmp/heap.hprof pid然后用MAT或VisualVM分析。注意线上环境抓dump会比较重我一般先抓GC日志确认是堆溢出级别的问题再动手dump避免给线上雪上加霜。第四步线上即时诊断推荐Arthasjava -jar arthas-boot.jar pidArthas的dashboard命令可以实时看到堆内存分区、GC次数和类加载情况heapdump命令可以直接生成堆转储文件classloader和sc命令能查到某个类实例的数量。相比jmapArthas对线上环境影响更小很多时候不必重启进程就能完成问题定位。3.3 GC日志分析实战GC日志是判断内存瓶颈的X光片。在jvm.options里提前配好-Xlog:gc*,gcagetrace,safepoint:file/var/log/elasticsearch/gc.log:utctime,uptimemillis,level,pid,tags:filecount32,filesize64m注意JDK 11的-Xlog语法跟JDK 8的-XX:PrintGCDetails已经不同。如果还在用JDK 8参考这种格式-XX:PrintGCDetails -XX:PrintGCDateStamps -XX:PrintGCTimeStamps -XX:PrintHeapAtGC -Xloggc:/var/log/elasticsearch/gc.log拿到GC日志后我一般先做三件事统计Full GC次数和时间间隔。连续多次Full GC且间隔很短说明堆内存已经是最顶层瓶颈。看GC pause的耗时分布。Young GC如果平均超过100ms说明堆过大或对象晋升太快Full GC如果超过几秒情况已经比较严峻。看GC前后堆使用率差。每次GC完内存释放不多说明堆里的长期存活对象太多——最常见就是fielddata缓存或request cache把堆吃住了。这里分享一个真实案例某次线上集群每5分钟一次Full GC堆从16G加到24G毫无好转。我抓了GC日志后发现每次Full GC完老年代占用纹丝不动堆里长期存活对象占了大半。用jmap -histo一查排第一的是一个聚合查询生成的上万个bucket对象。最终解决方式是改写DSL把一次超大规模terms聚合拆成多次composite聚合并给fielddata设置了熔断上限。没有动任何JVM参数问题直接消失。GC调参永远是最后一步前面的对象占用和请求设计才是真正的症结。4. 调优落地参数计算与配置模板4.1 按业务场景推算内存尺寸先给一个具体的计算示例。假设有一台64GB物理内存的裸金属节点预计承载1.2TB数据分片大小按单个shard 30GB计算总共需要约40个shard。如果集群有3个数据节点每个节点大概承担13-14个shard规模中等。内存分配我按这个节奏推算JVM堆物理内存的一半取30GB不超过30GB红线。fielddata熔断上限默认60%的堆也就是18GB。如果业务里聚合和排序比较重可以保留默认如果重聚合极多我建议把indices.breaker.fielddata.limit调到50%留下更多缓冲。query cache默认10%的堆约3GB如果查询模式比较重复按5%到10%之间调如果查询全随机调大也没意义。总熔断默认95%。我习惯调成85%左右给ES内部任务和系统操作留出缓冲空间。4.2 一份可直接抄的配置模板这是jvm.options里与内存强相关的配置片段适用于ES 7.16、JDK 11-Xms30g -Xmx30g -XX:UseG1GC -XX:MaxGCPauseMillis200 -XX:G1HeapRegionSize16m -XX:InitiatingHeapOccupancyPercent30 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/var/log/elasticsearch/heapdump.hprof -XX:ExitOnOutOfMemoryError注意最后两个参数HeapDumpOnOutOfMemoryError能在OOM自动生成堆转储ExitOnOutOfMemoryError则在OOM后主动退出进程而不是继续硬撑这样可以让集群把分片迁移到别的节点避免一个“僵尸节点”拖垮整个集群。elasticsearch.yml里的核心配置bootstrap.memory_lock: true indices.breaker.total.limit: 85% indices.breaker.fielddata.limit: 50% indices.breaker.request.limit: 60% indices.breaker.inflight_requests.limit: 85% indices.queries.cache.size: 5% indices.fielddata.cache.size: 20% indices.fielddata.cache.expire: 6h简单解释下最后两个参数indices.fielddata.cache.size限制了fielddata缓存的最大空间默认其实是无限大这是绝大多数fielddata OOM的根源我建议业务侧评估后设置一个明确上限expire设一个合理的过期时间避免冷数据长驻堆内。4.3 调优后的验证方法改完配置别急着宣布完工。ES提供了大量API可以直接验证调优效果。基础监控curl -s localhost:9200/_cat/nodes?vhname,heap.percent,ram.percent,cpu,load_1m,node.role看GC指标curl -s localhost:9200/_nodes/stats/jvm?pretty | grep -A 20 gc关注三个核心数据collection_countGC次数、collection_time_in_millisGC总耗时、还有young和old两个代各自的耗时。看缓存命中率curl -s localhost:9200/_nodes/stats/indices/query_cache?prettyhit_count和miss_count的比例可以算出命中率。如果命中率超过80%说明缓存配置比较有效如果每个查询都是不同的DSL命中率低也正常别硬调。判断调优是否“成功”我自己的标准有四个Full GC次数压到极低理想情况下数小时才一次甚至没有。单次GC pause稳定在200ms以下。JVM堆使用率峰值不超过85%不会出现断崖式忽高忽低。集群整体吞吐不降P99延迟比调优前持平或更低。至少观察24小时再下结论别只盯半小时监控就开心。线上流量有昼夜波动半天数据的说服力不够。5. 常见问题与排查技巧实录5.1 Circuit Breaker触发是失误还是真超限日志里出现CircuitBreakingException[data too large]的时候先别急着加堆。这个异常有两种常见情况一是某个查询确实太重。比如用户对高基数keyword字段做terms聚合桶数量达到几百万级别每个桶又有子聚合构建结果集时内存预估值直接冲顶。处理方法不是堆加内存而是改写查询限制桶数size、改用composite聚合分页取桶、在应用层做数据裁剪。二是熔断器参数和业务不匹配。比如indices.breaker.total.limit默认95%理论上很宽松但正因为太宽松反而容易让节点在真正OOM前没有任何保护。我反而会调低到85%宁可让个别超大请求失败也要保住节点稳定。记住熔断拒绝请求是可接受的节点宕机才是事故。5.2 Bulk写入内存暴涨写入冻结怎么办大批量写入时堆内存飙升通常有三个推手单批数据量过大、refresh间隔太短、segment merge压力太大。先看bulk单批大小。推荐单批数据体积控制在5MB到15MB之间而不是死板规定“一次1万条”。最稳妥的办法是先测从5MB开始逐渐往上加直到写入延迟开始抬升或者堆使用率显著上升就停在上一个档位。再看refresh间隔。如果默认的1秒刷新导致每秒钟都在生成新segment不仅磁盘压力大内存中等待刷新的buffer也会反复占用。业务上允许的话把index.refresh_interval调到10秒甚至30秒写入吞吐会明显改善。最后是merge。频繁的大段merge会占用不少堆内临时内存如果节点IO和CPU都高但堆并不算满可以检查分片数和段数量。分片过少导致单shard过大merge压力集中这时候加节点加内存都不如把分片规划调整好。5.3 字段爆炸增量式堆杀手我见过最隐蔽的堆内存天敌是动态mapping导致的字段爆炸。业务方往文档里塞了一堆动态字段很快索引的字段数从几十涨到几千。字段越多mapping越大fielddata和query cache的命中率越低GC压力随之上升。这个问题必须在建索引初期就想清楚。核心手段有这几个dynamic: false或dynamic: strict前者忽略未知字段后者直接拒绝写入。对已知字段明确类型能不用text就不用text能用keyword就坚决用keyword。关闭不需要的norms和doc_values减少索引结构和堆内存占用。多说一句改成严格模式要谨慎。先和应用方确认字段范围再上线不然生产上会有大量写入失败。我自己经历过一次切dynamic: strict后业务连夜告警的尴尬。5.4 Query Cache命中率低是不是缓存配置错了很多同学看到query cache命中率低就紧张上来就把indices.queries.cache.size调大。这里要讲清楚query cache的机制它是节点级别的、以segment为粒度的缓存只有完全相同的查询条件和过滤逻辑才能复用。如果业务查询基本都是“带随机参数的搜索”比如日志检索里每次都带不同的关键字那query cache命中率天然低这个跟参数没关系。真正值得优化的是filter cache的使用方式。对重复率高、基数低的过滤条件比如状态值、业务ID尽量用filter子句包裹使用query cache的效果就非常明显。同样的过滤条件如果在业务里被大量重复缓存命中带来的性能收益非常可观。indices.queries.cache.size默认10%的堆如果堆本身给了30GB就有3GB用于filter cache通常足够。我建议先从5%开始评估结合命中率调不要一上来就配到最大。调优ES内存这件事说白了就是“理解堆内堆外的分工再把每个区域的资源分配做到恰到好处”。我从踩过的坑里提炼的体会是不要迷信堆越大越好也不要追求完全没有GC。合理的状态是有GC但GC短促、频率低、不阻塞业务堆外Page Cache有充足空间查询不需要频繁碰磁盘。另一个深刻的教训就是改任何参数前先记录集群的基准状态增加一个参数观察一天别一次性改七八个配置出了问题你根本不知道是哪一刀切的。最后再分享一个小技巧线上环境提前把GC日志和OOM dump都打开看起来只是几行配置等真出事的时候你会发现这是救命稻草。调优不是一锤子买卖每次压测、每次大版本升级后都回去看一眼这五个指标堆使用率、Full GC次数、GC pause时间、query cache命中率、Page Cache状态。数据会告诉你下一步该往哪走。
