ElasticSearch CPU和内存占用高的优化记录出现GC

最新推荐文章于 2025-06-04 21:58:05 发布

原创

最新推荐文章于 2025-06-04 21:58:05 发布 · 7k 阅读

15 ·

CC 4.0 BY-SA版权

本文详细记录了一次ElasticSearch在数据报表汇总引擎中遇到的查询超时问题，通过逐步排查，发现CPU使用率高达300%，内存使用率达到90%。经过对线程、段(segment)、节点内存和CPU使用情况的深入分析，最终定位问题为JVM GC频繁导致，并通过调整JVM参数，如增加heap大小和更改GC策略，成功解决了性能瓶颈。

公司最近使用ElasticSearch作为数据报表汇总引擎.上线三个月累计数据800万,但是今天突然大面积出现查询超时,上服务器查看服务运行情况,发现cpu使用率高达300% mem 使用率也到了90%,下面记录了整个排查问题的过程

1.首先查看elastic cpu和mem占用情况

复制代码

//首先查看所有进程
# top
//找到对应的elasticserch运行的PID,查看占用内存比较高的线程,Ctrl+c 退出
#top -Hp 12345   
//为了下面方便调用API,将elasticsearch.yml
//   xpack.security.enabled: false
//关闭认证,重启elasticsearch

复制代码

2.确定是由于某个线程引起的状况,查询所有segment的驻留内存的情况

//kibana 以下全部以kibanna为例
GET  _cat/segments?v&h=index,segment,size
//curl
#curl -XGET 'http://10.0.7.134:9200/ _cat/segments?v&h=index,segment,size'

这里摘录一下,elasticsearch,

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

王树民

关注关注

1
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

深入理解Elasticsearch日志中的GC日志

2301_79366435的博客

09-19

613

GC（垃圾回收）是一种自动内存管理机制，用于管理Java虚拟机（JVM）中的对象分配和回收。在大数据应用程序中，如Elasticsearch，GC对于保持系统性能和稳定性至关重要。本文将深入探讨Elasticsearch日志中的GC日志，了解其含义和如何解读。同时，我们将提供相关的源代码示例以帮助读者更好地理解。在上面的示例中，我们可以看到四行GC日志记录。

Elasticsearch集群中节点的JVM内存使用率过高，GC频繁如何排查原因和处理？

maxcode

07-21

523

摘要：Elasticsearch集群节点JVM内存使用率过高、GC频繁问题可能由高查询/写入负载、索引设计不合理或GC配置不当导致。可通过检查慢查询日志、分片状态、GC日志和资源使用情况定位原因。解决方案包括优化复杂查询、限制字段缓存、调整写入批量大小、控制分片数量（10-50GB/分片）及优化GC策略。关键操作如使用search_after替代深分页、设置fielddata.cache.size、调整refresh_interval和监控heap_used_percent指标，可有效降低内存压力，提升集群

参与评论您还未登录，请先登录后发表或查看评论

Elasticsearch-高CPU优化

NCS123456的博客

06-21

2193

Elasticsearch使用线程池管理CPU资源，用于并发操作。如果某个节点的CPU使用率很高，可以使用该节点的热线程API（hot_threads）来检查节点上运行的资源密集型线程。如图所示，查询请求量的波动与集群最大CPU使用率是基本吻合的。确保对于节点上已配置的每个 GB的内存，将分片数量保持在 20 以下，如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片。查看查询/写请求量，分析是否cpu高和查询量升高或者写入量升高导致的。是操作系统层面的cpu消耗，不是我们重点优化对象。

ElasticSearch集群内存占用高？如何降低内存占用看这篇文章就够啦！（冻结索引）_es占用内存太大(1)

2401_84183802的博客

05-14

1623

在上述代码中，我们首先创建了一个 SearchRequest 对象，然后使用 IndicesOptions.fromOptions() 方法创建了一个 IndicesOptions 对象，并将参数设置为 false。这样，搜索请求将遵循指定的索引选项，而不使用默认的 ignoreThrottled 参数值。要设置 ignoreThrottled 参数为 false，您可以使用 IndicesOptions.fromOptions() 方法并传递适当的参数。

记录一次es的性能调优

www.shuaibo.wang|王帅博

03-06

2720

这是 JVM 垃圾回收过程中的一条日志，表示在最近 38.6 秒内，JVM 进行了一次 GC (Garbage Collection) 的操作，回收垃圾所占用的内存。这条日志的含义是，在这次 GC 中，有很大一部分时间（38.3 秒）是用于处理 GC 相关的开销（例如标记垃圾、整理内存等），而不是实际回收垃圾。除了垃圾回收器的选择之外，还可以调整 Elasticsearch 的垃圾回收策略参数。例如，可以调整堆内存的大小、垃圾回收的线程数、垃圾回收的阈值等参数，以达到更好的垃圾回收效果。

ElasticSearch集群内存占用高？如何降低内存占用看这篇文章就够啦！（冻结索引）

小赵的博客

11-16

3897

经常搜索的索引被保留在内存中，因为重建索引和帮助高效搜索需要花费时间。另一方面，可能存在我们很少访问的索引。这些。这样的索引称为。每当搜索分片时，Elasticsearch都会构建冻结索引的每个分片的即时数据结构，并在搜索完成后立即丢弃这些数据结构。因为Elasticsearch不会在内存中维护这些临时数据结构，所以冻结索引消耗的堆要比普通索引少得多。与其他方式相比，这允许更高的磁盘与堆的比率。

Elasticsearch内存分配设置详解

tao_wei162的博客

07-07

1164

Elasticsearch默认安装后设置的内存是1GB，对于任何一个现实业务来说，这个设置都太小了。如果你正在使用这个默认堆内存配置，你的集群配置可能会很快发生问题。这里有两种方式修改Elasticsearch的堆内存（下面就说内存好了），最简单的一个方法就是指定ES_HEAP_SIZE环境变量。服务进程在启动时候会读取这个变量，并相应的设置堆的大小。设置命令如下： export ES_H...

windows运行Elasticsearch内存占用过大

无

02-08

1228

运行Elasticsearch，内存占用过大

从ES的JVM配置起步思考JVM常见参数优化

热门推荐

张彦峰的博客

12-03

9万+

Java 8目前仍然是许多企业中主要使用的版本之一，尤其是对于比较保守的公司。在过去，CMS (Concurrent Mark-Sweep) 垃圾回收器在Java 8中是一种常见选择，因为它在某些场景下能够提供较好的性能。然而，随着Java版本的不断更新，一些旧的特性和组件被淘汰或替代，比如CMS。Java 14中正式废弃了CMS，而新的垃圾回收器，如ZGC和G1，逐渐成为了主流选择。ZGC和G1在处理大内存堆和低停顿时间方面表现出色，适用于现代应用程序的需求。

【Elasticsearch】Elasticsearch CPU高排查思路

九师兄

10-25

3117

1.概述 https://blog.youkuaiyun.com/laoyang360/article/details/79874984 https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-above.html#ignore-above https://discuss.elastic.co/t/es-high-cpu-usage-when-idle/87950/4

【DevOps】Elasticsearch为什么需要大内存，怎么优化？

TradingAgents-CN专栏

05-09

1747

在 Elasticsearch 中，分片（Shard）是索引的基本单位，每个索引由多个分片组成。每个分片实际上是一个独立的 Lucene 索引。Elasticsearch 需要大量内存来满足其快速索引、搜索和聚合的需求，同时也要维持高可用性和灵活性。合理配置内存和调整相关参数，可以显著提高 Elasticsearch 的性能和稳定性。通过合理规划分片数量和管理策略，可以有效降低 Elasticsearch 的内存占用。当前有 10 个分片，目标是将其缩减到 2 个分片。使用别名将新索引映射为旧索引名称。

Elasticsearch GC优化实践

h952520296的博客

11-22

2152

近期业务查询线上ES集群出现频繁超时告警，尤其是早晨某个时间点固定的报一波超时，从调用链监控上很难看出是什么业务行为导致的。

elasticsearch入库错误：gc overhead导致数据节点脱离集群

weixin_34029949的博客

04-11

2481

2019独角兽企业重金招聘Python工程师标准>>> ...

ElasticSearch gc overhead

lpfasd123的博客

05-08

3273

在实际使用中经常会有gc overhead异常，其原因是es的内存不足，在进行full gc时资源使用过多，导致心跳检测无法通过，被剔除集群,导致NoNodeAvailableException。如图： gc异常.png 在实际使用中，有以下几种处理方法： 1.增大jvm内存，这样使用gc的频次减少，但是full gc的时间更长 2.增加心跳检测的timeout时间，以避免检测节点...

【elasticsearch】elasticsearch集群占用太多虚拟内存(VIRT)的问题？

Mrerlou的博客

06-22

1318

前言 es集群虚拟映射内存高？ ES5.x以后，对于lucene索引文件改为mmap的方式进行访问，当索引被打开以后，ES会讲文件映射到虚拟内存空间，但并不会读取到物理内存里。只有索引文件被访问的时候，才会通过os将读取的部分从磁盘page in到物理内存。由于虚拟内存并不是实际的物理内存占用，并且os本身会管理映射内存的的page in/page out，看似很大很吓人的虚拟内存占用其实并无任何问题。并且在物理内存足够的情况下，这种方式通常可以提升ES对索引文件的访问速度。参考:http://

elasticsearch 频繁GC问题处理

fsckzyly的博客

12-25

295

收到ES的告警，在1小时内意外分配了碎片，从而导致集群状态 Green > Yellow > Red > Yellow > Green 频繁切换？在此期间，ES不可访问，并且调用API开始返回非200的状态码。环境 3个主节点和3个工作节点。错误分析 GC锯尺图这种锯尺模式的原因是，ELasticsearch在执行某些操作搜索查询，写入查询，刷新，刷新操作等，...

Elasticsearch 高内存占用分析与优化建议报告

喝醉酒的小白

06-04

1254

所有节点的堆内存仅为 4GB，占总内存比例不到 7%。堆使用率约在 46%~67%，说明已经接近警戒线。远低于推荐值（总内存的 50%，上限为 32GB），极易造成频繁 GC 或堆溢出。

elasticsearch配置内存占用

Zhang Phil

06-08

2945

Windows环境下elasticsearch起来后占用内存过高，可以通过配置修改elasticsearch占用的内存大小。涉及到elasticsearch的安装目录config文件夹下面的两个配置文件。elasticsearch.ymljvm.options（1）在elasticsearch.yml里面找到bootstrap.memory_lock: true，这一行，elasticsearch默认是把这一条配置注释掉没生效，去掉#号，打开使之生效。（2）在jvm.options里面，找到## -X

elasticsearch引起GC原因分析

11-27

1100

elasticsearch引起GC原因分析

在资源受限环境下如何优化Elasticsearch的内存配置？

最新发布

11-26

<think> 我们参考了多个引用，特别是引用[2]和引用[4]，它们提供了在资源受限环境下优化Elasticsearch内存配置的关键指导。引用[2]指出：Elasticsearch的内存分配主要分为两部分：Elasticsearch堆内存和Lucene使用的内存。其中，Elasticsearch堆内存应设置为不超过32GB且不超过节点总内存的50%，即取min(32G, 节点内存/2)。引用[4]则提供了一个轻量级部署方案，其中提到可以通过禁用某些非核心服务来减少资源占用，例如禁用Elasticsearch的某些功能（在特定场景下）或者调整部署模式。因此，在资源受限环境下优化Elasticsearch内存配置的方法如下： ### 一、核心优化原则 1. **堆内存设置**（根据引用[2]） - **上限规则**：设置`-Xms`和`-Xmx`为相同值，避免动态调整开销。大小取`min(32GB, 机器内存/2)`。 - **避免交换**：设置`bootstrap.memory_lock: true`锁定内存[^2]。 2. **Lucene内存管理**（引用[2]） - 剩余内存（约50%）供Lucene使用，用于文件系统缓存，加速索引和搜索。 3. **精简部署**（根据引用[4]） - 在非必要场景下，禁用非核心功能（如安全模块、高级监控等）以减少内存占用。 ### 二、具体优化步骤 #### 1. 调整JVM堆大小修改`jvm.options`文件（Docker环境可通过挂载卷修改）： ```ini # 示例：4GB内存的机器设置堆大小为2GB -Xms2g -Xmx2g ``` #### 2. 关闭非必要功能在`elasticsearch.yml`中禁用以下模块： ```yaml # 关闭安全模块（仅限内网环境） xpack.security.enabled: false # 关闭机器学习（若不需要） xpack.ml.enabled: false # 关闭Watcher（若不需要） xpack.watcher.enabled: false ``` #### 3. 优化线程池（资源受限环境）减少线程池数量以降低内存开销： ```yaml # elasticsearch.yml thread_pool: index: size: 1 # 原默认值=处理器数，改为1 search: size: 1 ``` #### 4. 调整索引设置 - **减少副本数**：`PUT /my_index/_settings { "index.number_of_replicas": 0 }` - **合并段**：强制合并只读索引`POST /my_index/_forcemerge?max_num_segments=1` #### 5. 使用轻量级替代组件（引用[4]）在资源极度受限时（如边缘计算），考虑替代方案： - 用**Redis**替代**RabbitMQ**（节省128MB内存）[^4] - 禁用Elasticsearch的BI分析功能（节省512MB+内存）[^4] ### 三、监控与验证 1. 检查堆内存使用率： ```bash GET /_cat/nodes?v&h=name,heap.percent ``` 目标：长期<75% 2. 查看文件系统缓存使用： ```bash GET /_nodes/stats/os?filter_path=**.file_system,**.memory ``` ### 四、极端优化场景若内存<4GB，采用以下策略： 1. **混合部署模式**：将主节点、数据节点、协调节点合并部署（仅限极小集群） 2. **限制分片数量**：`cluster.routing.allocation.total_shards_per_node: 5`（默认无限制） > **注意**：以上优化可能影响性能，需根据业务场景权衡。 ### 优化效果示例 | 配置项 | 默认值 | 优化后值 | 内存节省 | |----------------------|---------------|-------------|---------| | 堆内存 | 16GB | 1GB | 15GB | | 安全模块 | 启用 | 禁用 | ~200MB | | 索引副本数 | 1 | 0 | 减少50%磁盘占用 | | 线程池大小 | 8（8核CPU） | 1 | 减少线程栈内存 | ### 公式推导（内存分配）设节点总内存为$M$，则： - Elasticsearch堆内存：$H = \min(32\text{GB}, \frac{M}{2})$ - Lucene可用内存：$L = M - H \approx \frac{M}{2}$ 当$M < 4\text{GB}$时，$H$按比例缩减： $$ H = \begin{cases} 0.5\text{GB} & M \leq 2\text{GB} \\ 1\text{GB} & 2\text{GB} < M \leq 4\text{GB} \\ \min(32\text{GB}, M/2) & M > 4\text{GB} \end{cases} $$ 通过以上优化，可在资源受限环境下显著降低内存占用，同时保持基本功能可用[^2][^4]。 §§相关问题§§ 1. 如何监控Elasticsearch的内存使用情况？ 2. 在Kubernetes中如何动态调整Elasticsearch内存配置？ 3. Elasticsearch堆内存溢出（OOM）的常见原因及解决方法？ </think> ### 资源受限环境下优化Elasticsearch内存配置的方法以下是针对资源受限环境（内存<8GB）的Elasticsearch内存优化方案，结合核心原则和实践策略： #### 一、核心优化原则（基于引用[2][4]） 1. **堆内存黄金法则** - 设置堆内存不超过物理内存的50%：$Heap \leq \frac{1}{2} \times RAM_{total}$ - 绝对上限32GB：$Heap \leq \min(32GB, \frac{1}{2}RAM_{total})$[^2] - **示例**：4GB内存机器 → 堆内存上限2GB 2. **内存分配比例** ```mermaid pie title 内存分配模型 "Elasticsearch堆内存" : 50 "Lucene文件缓存" : 40 "OS保留内存" : 10 ``` #### 二、关键优化策略 1. **精简部署架构**（基于引用[4]） | 组件 | 默认资源 | 优化方案 | 节省效果 | |---|---|---|---| | 主节点 | 2GB+ | 与数据节点合并 | 减少512MB+ | | 协调节点 | 1GB+ | 禁用专用节点，由数据节点兼任 | 减少1GB | | 安全模块 | 300MB+ | 禁用xpack.security | 减少200MB+ | | 机器学习 | 500MB+ | 关闭xpack.ml | 减少400MB+ | 2. **JVM配置优化** ```yml # config/jvm.options -Xms1g # 初始堆=最大堆，避免动态调整 -Xmx1g -XX:UseG1GC # G1垃圾回收器（<4GB首选） -XX:MaxGCPauseMillis=200 ``` 3. **分片策略优化**（基于引用[1]） - 减少分片数量：`PUT /index/_settings { "index.number_of_shards": 1 }` - 关闭副本：`index.number_of_replicas: 0`（可恢复后再启用） - 合并只读索引：`POST /index/_forcemerge?max_num_segments=1` 4. **操作系统级优化** ```bash # 禁用swap sudo swapoff -a # 调整虚拟内存 sysctl -w vm.swappiness=1 # 增加文件描述符 ulimit -n 65536 ``` #### 三、极端资源场景方案（<4GB内存） 1. **混合节点部署** ```yml # elasticsearch.yml node.roles: [master, data, ingest] # 三合一节点 discovery.type: single-node # 单节点集群模式 ``` 2. **组件替代方案**（基于引用[4]） - 消息队列：用Redis替代RabbitMQ → 节省128MB[^4] - 存储引擎：SSD替代HDD → 减少内存缓存依赖 3. **内存限制公式** 设总内存为$M$ (GB)，推荐配置： $$ \begin{cases} Heap = \lfloor 0.4M \rfloor & \text{if } M \leq 4 \\ Heap = \min(32, \lfloor 0.5M \rfloor) & \text{if } M > 4 \end{cases} $$ #### 四、监控与验证 1. **健康检查命令** ```bash # 内存使用率 GET /_cat/nodes?v&h=name,ram.percent,heap.percent # 分片分布 GET /_cat/allocation?v ``` 2. **关键监控阈值** | 指标 | 警告阈值 | 危险阈值 | |---|---|---| | JVM堆使用率 | >75% | >85% | | 文件缓存命中率 | <90% | <80% | | 分片未分配数 | >0 | >5 | #### 五、优化效果示例 4GB内存服务器优化前后对比： | 配置项 | 默认值 | 优化后 | 内存节省 | |---|---|---|---| | 堆内存 | 2GB | 1.6GB | 400MB | | 线程池 | 自动 | 减半 | 200MB+ | | 副本数 | 1 | 0 | 减少50%磁盘缓存 | | 安全模块 | 启用 | 禁用 | 300MB | | **总计** | - | - | **900MB+** | > 通过上述方案，可在4GB内存机器上稳定运行小型集群（3节点），查询延迟控制在200ms内[^2][^4]。