版本： 5.4.2
jvm: 1.8
heap:30G
gc算法：g1
集群18个节点， 突然有一个节点出问题了，因为分片是分散在每个机器上的，因此查询被hang住了，几分钟打不开cerebro。
大概5-6分钟后集群开始恢复，从master节点上可以看到节点被踢出去了，ping超过了30s。
从日志上看，发现是节点的gc导致的 master探测失败，日志内容如下：
[gc][old][26688589][5] duration [27.8s], collections [1]/[37.9s], total [27.8s]/[1.9m], memory [26gb]->[23gb]/[30gb], all_pools {[young] [432mb]->[88
mb]/[0b]}{[survivor] [192mb]->[0b]/[0b]}{[old] [25.3gb]->[22.9gb]/[30gb]}
[2019-11-25T21:28:16,891][WARN ][o.e.m.j.JvmGcMonitorService] [] [gc][26688589] overhead, spent [37.7s] collecting in the last [37.9s]
30G的内存需要gc这么久，我看了下机器内存使用率，差不多维持在75%左右，应该是某个时间点触发了gc条件
但是不明白为什么使用了G1算法，gc导致的停顿时间还这么久呢
jvm: 1.8
heap:30G
gc算法：g1
集群18个节点， 突然有一个节点出问题了，因为分片是分散在每个机器上的，因此查询被hang住了，几分钟打不开cerebro。
大概5-6分钟后集群开始恢复，从master节点上可以看到节点被踢出去了，ping超过了30s。
从日志上看，发现是节点的gc导致的 master探测失败，日志内容如下：
[gc][old][26688589][5] duration [27.8s], collections [1]/[37.9s], total [27.8s]/[1.9m], memory [26gb]->[23gb]/[30gb], all_pools {[young] [432mb]->[88
mb]/[0b]}{[survivor] [192mb]->[0b]/[0b]}{[old] [25.3gb]->[22.9gb]/[30gb]}
[2019-11-25T21:28:16,891][WARN ][o.e.m.j.JvmGcMonitorService] [] [gc][26688589] overhead, spent [37.7s] collecting in the last [37.9s]
30G的内存需要gc这么久，我看了下机器内存使用率，差不多维持在75%左右，应该是某个时间点触发了gc条件
但是不明白为什么使用了G1算法，gc导致的停顿时间还这么久呢
1 个回复
匿名用户
赞同来自: