我的配置:
4台服务器组成的Elasticsearch集群,每台服务器只作为一个节点。
其中有两台数据节点
一台客户端节点
一台主节点
内存均为64G
启动命令:
docker run -d \
--name=espn-50 \
-p 9200:9200 \
-p 9300:9300 \
-v \
/var/espn/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \
-v \
/var/espn/data:/usr/share/elasticsearch/data elasticsearch:5.6.3
4台节点启动命令是一样的,暴露9200 9300端口,并挂载elasticsearch.yml及数据目录。
模拟了3个月数据,每天一个索引,索引数量90,每个索引有200W~300W条数据不等。
随着数据量增加,发现服务器CPU占用过多(没错,那两台数据节点)
查看这两台数据节点的elasticsearch日志:
[gc][1779997] overhead, spent [45.2s] collecting in the last [45.8s] //这行日志若干行,就数字不一样
再去查询节点情况:
curl 'localhost:9200/_cat/nodes?v=pretty'
发现数据节点的 heap.percent 百分之99。
通过查询资料,我总结出来大概是这样的:
- ES本身是Java项目,既然是Java项目,必然是运行在JVM上的,现在堆内存已满。
- 堆内存已满,Elasticsearch正在尝试GC,然而每次GC又打不到释放的效果,因此不断的在GC,不断的使用CPU,因此CPU使用严重。
- 索引数量比较多,而ES采用的倒排索引和segment这种机制,使得在比较多的索引而且索引数据必须要使用的情况下,必须调整JVM,也就是对JVM进行优化。
- ES默认的Heap太小,一般用来做大数据存储是不够的,大概率是要手动调整的(2.X 版本默认1G,5.6.3是2G)
查了一圈网上的资料,包括官网,发现一个蛋疼的事实:
不同版本的ES调整JVM的方法都不太一样。
我使用的是 Elasticsearch5.6.3 ,再次强调一下这一点。
解决的方法很简单,在elasticsearch的config文件夹下,改写jvm.options文件即可。(5.6.3的docker容器中没有这个文件,我新写了一个文件挂载到容器内也是生效的)
jvm.options:
-Xms10g
-Xmx10g
不熟悉的话可以学习一下JVM的相关知识。
启动指令:
docker run -d \
--name=espn-50 \
-p 9200:9200 \
-p 9300:9300 \
-v \
/var/espn/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml \
-v \
/var/espn/config/jvm.options:/usr/share/elasticsearch/config/jvm.options \
-v \
/var/espn/data:/usr/share/elasticsearch/data elasticsearch:5.6.3
将jvm.options也挂载到docker容器内。注意,jvm.options的权限应该是可读可写可执行的。
网友评论