怎么又是你

es频繁minor gc日志一直报超时

Elasticsearch | 作者 poka | 发布于2021年07月23日 | 阅读数:3670

elasticsearch 7.3 单机环境
linux 操作系统
给es分配内存为16G
 
运行es时,发现日志里一直报超时的错误。
 
查看gc日志发现频繁的minor gc操作,具体日志如下:
[2021-07-22T08:40:21.050+0000][9757][safepoint    ] Entering safepoint region: GenCollectForAllocation
[2021-07-22T08:40:21.051+0000][9757][gc,start     ] GC(89002) Pause Young (Allocation Failure)
[2021-07-22T08:40:21.051+0000][9757][gc,task      ] GC(89002) Using 13 workers of 13 for evacuation
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) Desired survivor size 56688640 bytes, new threshold 1 (max threshold 6)
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) Age table with threshold 1 (max threshold 6)
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) - age   1:   57037504 bytes,   57037504 total
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) - age   2:    1653320 bytes,   58690824 total
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) - age   3:     884096 bytes,   59574920 total
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) - age   4:     646296 bytes,   60221216 total
[2021-07-22T08:40:21.071+0000][9757][gc,age       ] GC(89002) - age   5:     668280 bytes,   60889496 total
[2021-07-22T08:40:21.071+0000][9757][gc,heap      ] GC(89002) ParNew: 950759K->69932K(996800K)
[2021-07-22T08:40:21.071+0000][9757][gc,heap      ] GC(89002) CMS: 2455862K->2455862K(15669696K)
[2021-07-22T08:40:21.071+0000][9757][gc,metaspace ] GC(89002) Metaspace: 99727K->99727K(1142784K)
[2021-07-22T08:40:21.071+0000][9757][gc           ] GC(89002) Pause Young (Allocation Failure) 3326M->2466M(16275M) 19.934ms
[2021-07-22T08:40:21.071+0000][9757][gc,cpu       ] GC(89002) User=0.20s Sys=0.00s Real=0.02s
[2021-07-22T08:40:21.071+0000][9757][safepoint    ] Leaving safepoint region
[2021-07-22T08:40:21.071+0000][9757][safepoint    ] Total time for which application threads were stopped: 0.0204659 seconds, Stopping threads took: 0.0000545 seconds
[2021-07-22T08:40:21.106+0000][9757][safepoint    ] Application time: 0.0352548 seconds
 
 
分析了一下gc日志,发现17个小时内发生了四千多的minor gc和4次full gc

微信截图_20210723101353.png


微信截图_20210723101426.png

 
这是否说明内存大小已出现了瓶颈?
 
 补充: 
分析gc日志的时候,发现jvm的Peak并未超过allocate的值,这是否说明内存其实够用,频繁full gc是因为其它原因?

微信截图_20210723140705.png


目前手边没有拿到 es的报错log日志,只有gc的Log。同事反馈Java 多线程写入时经常会报超时,连接失败。怀疑可能是线程数量不够(目前es线程数是16)。
 
已邀请:

tongchuan1992 - 学无止境、学以致用

赞同来自:

您好,具体还是得看数据写入量以及查询策略用没有用到缓存。minor gc 可以不用优化,full gc 一天出现一次我觉得比较正常,出现四次,可以换种其他的gc方法,或者增加jvm内存。

bufanyun - es小白

赞同来自:

看看报错

a2dou

赞同来自:

频繁full gc说明内run确实捉襟见肘了。我的经验是,闲时内存用量占jvm内存的50-60%左右比较好,集群可以较好的应对短时间大量查询,并且很少出现full gc。

要回复问题请先登录注册