成都的es集群经常出现告警,查看日志发现
[gc][11534155] overhead, spent [38.3s] collecting in the last [38.6s]
这是 JVM 垃圾回收过程中的一条日志,表示在最近 38.6 秒内,JVM 进行了一次 GC (Garbage Collection) 的操作,回收垃圾所占用的内存。这条日志的含义是,在这次 GC 中,有很大一部分时间(38.3 秒)是用于处理 GC 相关的开销(例如标记垃圾、整理内存等),而不是实际回收垃圾。
这可能是因为堆内存中的对象数量太多,导致 GC 操作变得缓慢。可以尝试通过调整 JVM 的垃圾回收策略、调整堆内存大小等方式来优化性能。
这里谈谈jvm的垃圾回收策略
一般来说,使用 G1 垃圾收集器可能比较适合 Elasticsearch。G1 是一种面向服务端应用的低延迟、高吞吐量垃圾回收器,可以根据内存使用情况动态地调整堆内存的分配比例,并且不会出现长时间的停顿。
下面是g1垃圾回收器的常用参数
除了垃圾回收器的选择之外,还可以调整 Elasticsearch 的垃圾回收策略参数。例如,可以调整堆内存的大小、垃圾回收的线程数、垃圾回收的阈值等参数,以达到更好的垃圾回收效果。具体的调整方法可以参考 Elasticsearch 的官方文档,以及相关的调优指南。
要在 Elasticsearch 6.3.2 中启用 G1 垃圾回收器,需要进行以下步骤(将其他垃圾回收器关掉):
编辑 Elasticsearch 的 JVM 配置文件 config/jvm.options,加入以下参数:
-XX:+UseG1GC
-XX:G1ReservePercent=25
-XX:InitiatingHeapOccupancyPercent=30
-XX:MaxGCPauseMillis=200
-XX:+ParallelRefProcEnabled
-XX:-OmitStackTraceInFastThrow
其中,-XX:+UseG1GC 启用 G1 垃圾回收器,其余参数用于优化 G1 的性能和行为。
确认 Elasticsearch 进程的运行用户并给予该用户对 Elasticsearch 安装目录及其子目录的读写权限。
上一篇:Python3-数据结构