使用netstat -lntp来看看有侦听在网络某端口的进程。当然,也可以使用 lsof。

集群分片数非常多的情况下,是否会造成master节点频繁gc

Elasticsearch | 作者 shwtz | 发布于2023年05月15日 | 阅读数:2329

es6.4
5master 30 hot data 36 cold data 2client
shards 3.9万多, data size 151.4TB

发现master节点频繁gc,虽然heap使用率不会特别高, 但是gc时间占比还挺长的,不知道是不是分片数据太多造成的?还是说是有客户端直接请求master?
 

mastergc.png

 
已邀请:

xiaohei

赞同来自: shwtz

shard 3.9万多,这也太多了,记得腾讯有个分享,shard过万就会有很多问题。
可以看下官网的文章: 
how-many-shards-should-i-have-in-my-elasticsearch-cluster
 
Data节点:
有一个很好的经验法则:确保对于节点上已配置的每个 GB,将分片数量保持在 20 以下。
如果某个节点拥有 30GB 的堆内存,那其最多可有 600 个分片,但是在此限值范围内,您设置的分片数量越少,效果就越好。一般而言,这可以帮助集群保持良好的运行状态。(编者按:从 8.3 版开始,我们大幅减小了每个分片的堆使用量,因此对本博文中的经验法则也进行了相应更新。请按照以下提示了解 8.3+ 版本的 Elasticsearch。)
 
Master节点维护的ClusterState,数据量会非常庞大,频繁GC肯定是正常现象。

kin122

赞同来自:

会的 老版本会更严重

要回复问题请先登录注册