elasticsearch 的日志gc

最新推荐文章于 2022-07-05 22:27:55 发布
最新推荐文章于 2022-07-05 22:27:55 发布
阅读量1.4k 收藏 2
点赞数 1
分类专栏： 性能评估 ELK
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wangshuminjava/article/details/107040838
版权

 

 

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

看到其中的[gc]关键词你也猜到了这是与 GC 相关的日志，那么你了解每一部分的含义吗？如果不了解，你可以继续往下看了。

我们先从最简单的看起：

  1. 第一部分是日志发生的时间
  2. 第二部分是日志级别，这里分别是WARN和INFO
  3. 第三部分是输出日志的类，我们后面也会讲到这个类
  4. 第四部分是当前 ES 节点名称
  5. 第五部分是 gc 关键词，我们就从这个关键词聊起。

友情提示：对 GC 已经了如指掌的同学，可以直接翻到最后看答案。

1. 什么是 GC？

GC，全称是 Garbage Collection （垃圾收集）或者 Garbage Collector(垃圾收集器)。

在使用 C语言编程的时候，我们要手动的通过 malloc 和 free来申请和释放数据需要的内存，如果忘记释放内存，就会发生内存泄露的情况，即无用的数据占用了宝贵的内存资源。而Java 语言编程不需要显示的申请和释放内存，因为 JVM 可以自动管理内存，这其中最重要的一部分就是 GC，即 JVM 可以自主地去释放无用数据（垃圾）占用的内存。

我们研究 GC 的主要原因是 GC 的过程会有 Stop The World(STW)的情况发生，即此时用户线程会停止工作，如果 STW 的时间过长，则应用的可用性、实时性等就下降的很厉害。

GC主要解决如下3个问题：

  1. 如何找到垃圾？
  2. 如何回收垃圾？
  3. 何时回收垃圾？

我们一个个来看下。

1.1 如何找到垃圾？

所谓垃圾，指的是不再被使用（引用）的对象。Java 的对象都是在堆(Heap)上创建的，我们这里默认也只讨论堆。那么现在问题就变为如何判定一个对象是否还有被引用，思路主要有如下两种：

  1. 引用计数法，即在对象被引用时加1，去除引用时减1，如果引用值为0，即表明该对象可回收了。
  2. 可达性分析法，即通过遍历已知的存活对象(GC Roots)的引用链来标记出所有存活对象

方法1简单粗暴效率高，但准确度不行，尤其是面对互相引用的垃圾对象时无能为力。

方法2是目前常用的方法，这里有一个关键是 GC Roots，它是判定的源头，感兴趣的同学可以自己去研究下，这里就不展开讲了。

image

1.2 如何回收垃圾？

垃圾找到了，该怎么回收呢？看起来似乎是个很傻的问题。直接收起来扔掉不就好了？！对应到程序的操作，就是直接将这些对象占用的空间标记为空闲不就好了吗？那我们就来看一下这个基础的回收算法：标记-清除(Mark-Sweep)算法。

1.2.1 标记-清除 算法(Mark Sweep)

该算法很简单，使用通过可达性分析分析方法标记出垃圾，然后直接回收掉垃圾区域。它的一个显著问题是一段时间后，内存会出现大量碎片，导致虽然碎片总和很大，但无法满足一个大对象的内存申请，从而导致 OOM，而过多的内存碎片（需要类似链表的数据结构维护），也会导致标记和清除的操作成本高，效率低下，如下图所示：

image

1.2.2 复制算法(Copying)

为了解决上面算法的效率问题，有人提出了复制算法。它将可用内存一分为二，每次只用一块，当这一块内存不够用时，便触发 GC，将当前存活对象复制(Copy)到另一块上，以此往复。这种算法高效的原因在于分配内存时只需要将指针后移，不需要维护链表等。但它最大的问题是对内存的浪费，使用率只有 50%。

但这种算法在一种情况下会很高效：Java 对象的存活时间极短。据 IBM 研究，Java 对象高达 98% 是朝生夕死的，这也意味着每次 GC 可以回收大部分的内存，需要复制的数据量也很小，这样它的执行效率就会很高。

image

1.2.3 标记-整理算法(Mark Compact)

该算法解决了第1中算法的内存碎片问题，它会在回收阶段将所有内存做整理，如下图所示：

image

但它的问题也在于增加了整理阶段，也就增加了 GC 的时间。

1.2.4 分代收集算法(Generation Collection)

既然大部分 Java 对象是朝生夕死的，那么我们将内存按照 Java 生存时间分为 新生代(Young) 和 老年代(Old)，前者存放短命僧，后者存放长寿佛，当然长寿佛也是由短命僧升级上来的。然后针对两者可以采用不同的回收算法，比如对于新生代采用复制算法会比较高效，而对老年代可以采用标记-清除或者标记-整理算法。这种算法也是最常用的。JVM Heap 分代后的划分一般如下所示，新生代一般会分为 Eden、Survivor0、Survivor1区，便于使用复制算法。

image

将内存分代后的 GC 过程一般类似下图所示：

image

  1. 对象一般都是先在 Eden区创建
  2. 当Eden区满，触发 Young GC，此时将 Eden中还存活的对象复制到 S0中，并清空 Eden区后继续为新的对象分配内存
  3. 当Eden区再次满后，触发又一次的 Young GC，此时会将 Eden和S0中存活的对象复制到 S1中，然后清空Eden和S0后继续为新的对象分配内存
  4. 每经过一次 Young GC，存活下来的对象都会将自己存活次数加1，当达到一定次数后，会随着一次 Young GC 晋升到 Old区
  5. Old区也会在合适的时机进行自己的 GC

1.2.5 常见的垃圾收集器

前面我们讲了众多的垃圾收集算法，那么其具体的实现就是垃圾收集器，也是我们实际使用中会具体用到的。现代的垃圾收集机制基本都是分代收集算法，而 Young与 Old区分别有不同的垃圾收集器，简单总结如下图：

image

从上图我们可以看到 Young与 Old区有不同的垃圾收集器，实际使用时会搭配使用，也就是上图中两两连线的收集器是可以搭配使用的。这些垃圾收集器按照运行原理大概可以分为如下几类：

  • Serial GC，串行，单线程的收集器，运行 GC 时需要停止所有的用户线程，且只有一个 GC 线程
  • Parallel GC，并行，多线程的收集器，是 Serial 的多线程版，运行时也需要停止所有用户线程，但同时运行多个 GC 线程，所以效率高一些
  • Concurrent GC，并发，多线程收集器，GC 分多阶段执行，部分阶段允许用户线程与 GC 线程同时运行，这也就是并发的意思，大家要和并行做一个区分。
  • 其他

我们下面简单看一下他们的运行机制。

1.2.5.1 Serial GC

该类 Young区的为 Serial GC，Old区的为Serial Old GC。执行大致如下所示：

image

1.2.5.2 Parallel GC

该类Young 区的有 ParNew和 Parallel Scavenge，Old 区的有Parallel Old。其运行机制如下，相比 Serial GC ，其最大特点在于 GC 线程是并行的，效率高很多：

image

 

1.2.5.3 Concurrent Mark-Sweep GC

该类目前只是针对 Old 区，最常见就是CMS GC，它的执行分为多个阶段，只有部分阶段需要停止用户进程，这里不详细介绍了，感兴趣可以去找相关文章来看，大体执行如下：

image

1.2.5.4 其他

目前最新的 GC 有G1GC和ZGC，其运行机制与上述均不相同，虽然他们也是分代收集算法，但会把 Heap 分成多个 region 来做处理，这里不展开讲，感兴趣的可以参看最后参考资料的内容。

image

1.2.6 Elasticsearch 的 GC 组合

Elasticsearch 默认的 GC 配置是CMS GC ，其 Young 区用 ParNew，Old 区用CMS，大家可以在 config/jvm.options中看到如下的配置：

 

## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

1.3 何时进行回收？

现在我们已经知道如何找到和回收垃圾了，那么什么时候回收呢？简单总结如下：

  1. Young 区的GC 都是在 Eden 区满时触发
  2. Serial Old 和 Parallel Old 在 Old 区是在 Young GC 时预测Old 区是否可以为 young 区 promote 到 old 区 的 object 分配空间，如果不可用则触发 Old GC。这个也可以理解为是 Old区满时。
  3. CMS GC 是在 Old 区大小超过一定比例后触发，而不是 Old 区满。这个原因在于 CMS GC 是并发的算法，也就是说在 GC 线程收集垃圾的时候，用户线程也在运行，因此需要预留一些 Heap 空间给用户线程使用，防止由于无法分配空间而导致 Full GC 发生。

2. GC Log 如何阅读？

前面讲了这么多，终于可以回到开篇的问题了，我们直接来看答案

 

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[gc][这是第228384次GC 检查] 在最近 2.3 s 内花了 2.2s 用来做垃圾收集，这占比似乎有些过了，请抓紧来关注下。

 

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

我们直接来看具体的含义好了，相信有了前面的 GC 基础知识，大家在看这里解释的时候就非常清楚了。

  • [gc][本次是 old GC][这是第228385次 GC 检查][从 JVM 启动至今发生的第 160772次 GC]

  • duration [本次检查到的 GC 总耗时 5 秒，可能是多次的加和],

  • collections [从上次检查至今总共发生1次 GC]/[从上次检查至今已过去 5.1 秒],

  • total [本次检查到的 GC 总耗时为 5 秒]/[从 JVM 启动至今发生的 GC 总耗时为 4.4 天]，

  • memory [ GC 前 Heap memory 空间]->[GC 后 Heap memory 空间]/[Heap memory 总空间],

  • all_pools(分代部分的详情) {[young 区][GC 前 Memory ]->[GC后 Memory]/[young区 Memory 总大小] } {[survivor 区][GC 前 Memory ]->[GC后 Memory]/[survivor区 Memory 总大小] }{[old 区][GC 前 Memory ]->[GC后 Memory]/[old区 Memory 总大小] }

3. 看看源码

从日志中我们可以看到输出这些日志的类名叫做JvmGcMonitorService，我们去源码中搜索很快会找到它/Users/rockybean/code/elasticsearch/core/src/main/java/org/elasticsearch/monitor/jvm/JvmGcMonitorService.java，这里就不详细展开讲解源码了，它执行的内容大概如下图所示:

image

关于打印日志的格式在源码也有，如下所示：

 

private static final String SLOW_GC_LOG_MESSAGE =
"[gc][{}][{}][{}] duration [{}], collections [{}]/[{}], total [{}]/[{}], memory [{}]->[{}]/[{}], all_pools {}";
private static final String OVERHEAD_LOG_MESSAGE = "[gc][{}] overhead, spent [{}] collecting in the last [{}]";

另外细心的同学会发现输出的日志中 gc 只分了 young 和 old ，原因在于 ES 对 GC Name 做了封装，封装的类为：org.elasticsearch.monitor.jvm.GCNames，相关代码如下：

 

    public static String getByMemoryPoolName(String poolName, String defaultName) {
        if ("Eden Space".equals(poolName) || "PS Eden Space".equals(poolName) || "Par Eden Space".equals(poolName) || "G1 Eden Space".equals(poolName)) {
            return YOUNG;
        }
        if ("Survivor Space".equals(poolName) || "PS Survivor Space".equals(poolName) || "Par Survivor Space".equals(poolName) || "G1 Survivor Space".equals(poolName)) {
            return SURVIVOR;
        }
        if ("Tenured Gen".equals(poolName) || "PS Old Gen".equals(poolName) || "CMS Old Gen".equals(poolName) || "G1 Old Gen".equals(poolName)) {
            return OLD;
        }
        return defaultName;
    }

    public static String getByGcName(String gcName, String defaultName) {
        if ("Copy".equals(gcName) || "PS Scavenge".equals(gcName) || "ParNew".equals(gcName) || "G1 Young Generation".equals(gcName)) {
            return YOUNG;
        }
        if ("MarkSweepCompact".equals(gcName) || "PS MarkSweep".equals(gcName) || "ConcurrentMarkSweep".equals(gcName) || "G1 Old Generation".equals(gcName)) {
            return OLD;
        }
        return defaultName;
    }

在上面的代码中，你会看到很多我们在上一节中提到的 GC 算法的名称。

至此，源码相关部分也讲解完毕，感兴趣的大家可以自行去查阅。

4. 总结

讲解 GC 的文章已经很多，本文又唠唠叨叨地讲一遍基础知识，是希望对于第一次了解 GC 的同学有所帮助。因为只有了解了这些基础知识，你才不至于被这些 GC 的输出吓懵。希望本文对你理解 ES 的 GC 日志 有所帮助。

5. 参考资料

  1. Java Hotspot G1 GC的一些关键技术（https://mp.weixin.qq.com/s/4ufdCXCwO56WAJnzng_-ow）
  2. Understanding Java Garbage Collection（https://www.cubrid.org/blog/understanding-java-garbage-collection）
  3. 《深入理解Java虚拟机：JVM高级特性与最佳实践》

 

 

王树民
关注
  • 1
    点赞
  • 踩
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
elasticsearch日志
08-19
es日志
nginx日志导入elasticsearch的方法示例
09-29
主要介绍了nginx日志导入elasticsearch的方法示例，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
elasticsearch-8.2.3 windows 版本
06-21
elasticsearch-8.2.3 windows 版本。 Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。Elasticsearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。官方客户端在Java、.NET（C#）、PHP、Python、Apache Groovy、Ruby和许多其他语言中都是可用的。根据DB-Engines的排名显示，Elasticsearch是最受欢迎的企业搜索引擎，其次是Apache Solr，也是基于Lucene
基于logstash实现日志文件同步elasticsearch
01-19
引言： 之前博文介绍过了mysql/oracle与ES之间的同步机制。而logstash最初始的日志同步功能还没有介绍。本文就logstash同步日志到ES做下详细解读。 1、目的： 将本地磁盘存储的日志文件同步（全量同步、实时增量同步）到ES中。 2、源文件： [root@5b9dbaaa148a test_log]# ll -rwxrwxrwx 1 root root 170 Jul 5 08:02 logmachine.sh -rw-r--r-- 1 root root 66 Jul 5 08:25 MProbe01.log -rw-r--r-- 1 root root 74
Elasticsearch recovery.RecoveryFailedException: [xxx][0]: Recovery failed on {node-1} --- 采坑
qq_41497111的博客
06-19 3229
问题描述; 服务器断电，es 直接挂掉，再次启动时，因以前数据量过大，大约500g，单机版es 启动恢复数据很是吃力，jvm 回收频繁。 [2019-06-17T16:24:14,303][INFO ][o.e.m.j.JvmGcMonitorService] [node-1] [gc][20] overhead, spent [319ms] collecting in the la...
Elasticsearch的[monitor.jvm]垃圾回收日志
热门推荐
Jeffrey Zhou 的专栏
04-20 1万+
Elasticsearch是构建在Java之上的、开源的、分布式搜索和分析引擎，因此JVM的性能对Elasticsearch性能至关重要。在负载超出节点所能承受的情况下，JVM垃圾内存回收的“Stop-The-World”会造成节点被踢出Elasticsearch集群。如果只是偶尔发生，Elasticsearch的冗余设计可以克服。如果是经常出现节点被踢出的情况，则会对整个集群的稳定造成影响。
聊聊Elasticsearch的MonitorService
weixin_34124939的博客
05-26 812
序 本文主要研究一下Elasticsearch的MonitorService MonitorService elasticsearch-7.0.1/server/src/main/java/org/elasticsearch/monitor/MonitorService.java public class MonitorService extends AbstractLifecycleCompon...
elasticsearch 一次性查询数据量过大 jvm内存快速占用满 导致集群无响应
cnamam的博客
07-05 3038
近期因为生产上es集群出现了内存快速占用满、频繁gc、集群无响应的现象，查看集群日志和满查询日志，发现都是因为频繁gc集群无响应后出现的报错、gc高频的警告以及平时不慢的查询报文出现在慢查询日志里。 看kibana的监控，发现内存几乎是在几秒内就占用满，并且满了以后，由于可用内存不足就开始频繁的full gc，cpu居高不下，集群此时基本在无法响应的状态，有遇到这种情况，只能重启才能解决，无法自己恢复，内存虽然已经占用满，但是集群日志中没有OOM的异常，而且出现的概率比较随机。 由于之前没有遇到过这个问题，
一文掌握并应用Elasticsearch中的GC实现垃圾日志处理
大JAVA解决方案
07-06 1368
如果你关注过 Elasticsearch 的日志，可能会看到如下类似的内容： [2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s] [2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][
jvm 调优命令 和方法
A初夏1的博客
07-13 508
jvm 调优命令 和方法一、 命令方法总结：参考资料（1）（2）（3）(4)(5)（6）（7）（8）(9)（10）测试 示例总结：1、2、 一、 命令方法总结： 你好！ 这是你第一次使用 Markdown编辑器 所展示的欢迎页。如果你想学习如何使用Markdown编辑器, 可以仔细阅读这篇文章，了解一下Markdown的基本语法知识。 参考资料 链接: https://www.jianshu.com/p/15597b3d2da8. 链接: https://blog.csdn.net/u013068789/a
【Elasticsearch】你看懂 Elasticsearch Log 中的 GC 日志了吗？
九师兄
06-06 1803
1.概述 转载：https://elasticsearch.cn/article/812 如果你关注过 elasticsearch 的日志，可能会看到如下类似的内容： [2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s] [2018-06-30T17:57:29,020][INFO ].
centos7中配置elasticsearch集群和离线安装x-pack
山鬼谣的专栏
04-05 1万+
环境操作系统:win7 虚拟机：centos7 elasticsearch：5.2.2步骤前提条件由于我是自己学习用，笔记本的内存有限，所以想在一台虚拟机中配置集群。 我虚拟机的情况是，已经安装好了elasticsearch、kibana、x-pack.网上的一般做法是把已经安装好得elasticsearch目录再复制一遍，而我呢！由于保存了安装包，所以又重新解压了一份并且重命名为elasti
搞java开发，看懂JVM的GC日志真的很重要
独行侠梦的博客
03-26 2413
前言 今天整理的这篇文章，整理自以前记录的日常笔记。 刚开始接触JVM时，对待GC的日志，是保持"逃避"态度的，线上部署的程序没有达到期望的运行效率，或是预期目标时，往往会把问题的矛头指向内存上。 是不是内存不够？ GC日志怎么这么多？占用磁盘高达几个G? 不想看到打印怎么多，甚至暴力的将程序日志屏蔽掉。 我也曾经这样干过，写过的程序，同样导致过内存溢出，甚至是主机宕机。 是的，java中的垃...
elasticsearch入库错误：gc overhead导致数据节点脱离集群
weixin_34029949的博客
04-11 2328
2019独角兽企业重金招聘Python工程师标准>>> ...
Elasticsearch：管理 Elasticsearch 内存并进行故障排除
Elastic 中国社区官方博客
05-18 2508
随着 Elastic 扩展我们的 Elasticsearch Service Cloud 产品和自动上线，我们已经将 Elastic Stack 的受众范围从完整的运营团队扩展到了数据工程师，安全团队和顾问。作为 Elastic 支持团队的代表，我喜欢与更多用户背景甚至更广泛的用例进行交互。 在更广泛的听众中，我看到了更多有关管理资源分配的问题，尤其是神秘的 shard 堆比率和避免使用熔断器（circuit breaker）的问题。我完全理解！当我开始使用 Elastic Stack 时，我遇到了同样的
elasticsearch-5.1.2安装pinyin分词器并测试
weixin_33751566的博客
01-20 622
2019独角兽企业重金招聘Python工程师标准>>> ...
Eleastisearch6.0.0由单节点升级到多节点集群cluster时候出现的分片同步错误问题解决
克隆大菠萝的超市
01-18 1万+
启动多个节点的ES后，ES开始推举master节点并同步分片shard数据到新ES节点上，此时观察Logstash日志抛出以下错误：logstash.outputs.elasticsearch] retrying failed action with response code: 403 ({"type"=>"cluster_block_exception", "reason"=>"blocked
查看elasticsearch write日志
最新发布
05-25
Elasticsearch的写入日志可以在Elasticsearch的日志文件中找到。默认情况下，它们位于Elasticsearch安装目录下的logs文件夹中。 如果您使用的是Linux或Mac OS操作系统，请在终端中使用以下命令查看最近100行的Elasticsearch日志： ``` tail -n 100 /path/to/elasticsearch/logs/*.log ``` 如果您使用的是Windows操作系统，请在命令提示符中使用以下命令： ``` type C:\path\to\elasticsearch\logs\*.log | Select-Object -Last 100 ``` 请注意，这些命令假定您将Elasticsearch安装在默认位置。如果您将其安装在不同的位置，请相应地更改路径。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值