Elasticsearch7.5.2集群节点偶发GC导致CPU突高问题排查求助

现有7节点Elasticsearch v7.5.2集群，单节点总内存32GB，分配给ES堆内存16GB，近期节点频繁出现偶发CPU峰值，同时伴随GC异常，问题节点相关监控如下：

• 查询负载不合理：存在未优化的慢查询，例如wildcard前缀匹配、大跨度范围查询、无路由的全集群查询、高复杂度聚合查询，这类查询会一次性加载大量数据到堆内存，触发频繁GC同时占用大量CPU资源做内存计算
• 写入负载不合理：批量写入批次过大、单次写入文档体积过大、未做索引生命周期管理导致冷热数据同存、大量字段动态映射导致不必要的索引构建，写入过程中产生的临时对象过多触发GC，同时段的索引构建、segment merge操作会占用大量CPU
• JVM参数配置不合理：虽然堆内存分配符合指针压缩要求，但可能存在GC收集器配置错误，例如7.x默认G1但调整了不合理的Region大小、XX:MaxGCPauseMillis设置过小导致GC频繁触发
• Segment Merge/Refresh操作频繁：索引refresh间隔设置过短会导致大量小segment生成，后台merge操作需要消耗大量CPU和内存，同时大量小segment会增加查询时的内存开销触发GC
• 版本已知内存泄漏问题：7.5.2版本存在多个公开的内存泄漏问题，例如查询缓存溢出、percolator相关内存泄漏、聚合查询产生的临时对象未被及时回收的bug
• 节点负载不均：分片分配不合理，热点分片集中在少数节点，导致单节点承担远超平均的查询/写入压力，触发CPU峰值和GC异常

• 排查慢查询日志：开启索引慢查询日志，设置查询超过500ms、写入超过200ms的阈值打日志，定位是否存在大开销查询；执行GET _cat/tasks?v查看当前运行中的任务，找到占用CPU/内存高的任务ID后执行GET _tasks/<task_id>?human查看任务详情
• 查看JVM运行状态：执行GET _nodes/stats/jvm?human查看堆内存使用占比、GC耗时/频率，重点看Old GC的次数和耗时，如果Old GC频繁且单次耗时超过1s，基本可以判定是堆内存被大对象占满无法回收
• 排查分片分布：执行GET _cat/shards?v查看分片是否集中在少数节点，是否存在超过30G的过大分片，过大分片会显著增加查询开销
• 查看索引配置：执行GET <index_name>/_settings查看refresh_interval、merge策略配置，确认是否存在refresh间隔过短、merge线程数设置过高的问题
• 核对版本bug：核对7.5.2版本的官方release note，确认是否命中和GC、CPU相关的已知bug

• 查询侧优化：禁用无必要的wildcard前缀查询，替换为ngram/keyword分词优化；高复杂度聚合查询拆分为多段小聚合，添加必要的路由键减少查询扫描的分片数；调整indices.queries.cache.size参数控制查询缓存占用，避免缓存溢出
• 写入侧优化：调整批量写入大小到单批次10-15M，不要超过50M；非实时业务场景调整refresh_interval到30s-5min；开启索引生命周期管理，冷数据归档到冷节点或者关闭，减少活跃分片占用的资源；禁用不必要的动态映射，提前规划字段类型，避免大字段冗余索引为text类型
• JVM优化：保持16G堆内存的配置，不要调整超过31G避免指针压缩失效；保持默认G1收集器配置，调整-XX:MaxGCPauseMillis为200-300ms，不要设置过低导致GC频繁触发；剩余16G系统内存留给Lucene做文件缓存即可，无需额外分配给堆内存
• 集群配置优化：调整单分片大小到10-30G区间，均衡分片分布避免热点节点；限制segment merge的线程数，机械盘设置为1，SSD设置为2-4，避免merge占用过多CPU；升级到7.5.2的最新补丁版或者更高的稳定小版本，修复已知的内存泄漏bug

内容的提问来源于stack exchange，提问作者cinove