tips:首先在es集群的生产环境中,一般不建议单机部署多实例,如果使用的是一台高配(高内存)物理机,内存≥512GB,单实例部署就有点浪费资源了,此时应考虑单机多实例部署。
① 堆内存:Elasticsearch 默认安装后设置的堆内存是2GB。 对于任何一个业务部署来说, 这个设置都太小了。如果你正在使用这些默认堆内存配置,您的集群可能会出现问题。
修改方式:
jvm.options配置
-Xms32g
-Xmx32g
或者 修改/etc/sysconfig/elasticsearch
ES_JAVA_OPTS="-Xms32g -Xmx32g"
请确保堆内存最小值(xms)与最大值(xmx)的大小是相同的,防止程序在运行时改变堆内存大小, 这是一个很耗系统资源的过程。
② 把服务器内存(少于)一半给Lucene
一个常见的问题是给 Elasticsearch 分配的内存太大了。假设你有一个64GB 内存的机器,如果把64GB 内存全都给 Elasticsearch。因为越多越好啊!
当然,内存对于 Elasticsearch 来说绝对是重要的,它可以被许多内存数据结构使用来提供更快的操作。但是说到这里, 还有另外一个内存消耗大户非堆内存(off-heap):Lucene。
Lucene 被设计为可以利用操作系统底层机制来缓存内存数据结构。 Lucene 的段是分别存储到单个文件中的。因为段是不可变的,这些文件也都不会变化,这是对缓存友好的,同时操作系统也会把这些段文件缓存起来,以便更快的访问。
Lucene 的性能取决于和操作系统的相互作用。如果你把所有的内存都分配给 Elasticsearch 的堆内存,那将不会有剩余的内存交给 Lucene。 这将严重地影响全文检索的性能。
标准的建议是把 50% 的可用内存作为 Elasticsearch 的堆内存,保留剩下的 50%。当然它也不会被浪费,Lucene 会很乐意利用起余下的内存。
如果你不需要对分词字符串做聚合计算(例如,不需要 fielddata )可以考虑降低堆内存。堆内存越小,Elasticsearch(更快的 GC)和 Lucene(更多的内存用于缓存)的性能越好。
③ 不要超过 32 GB!
这里有另外一个原因不分配大内存给 Elasticsearch。事实上 , JVM 在内存小于 32 GB 的时候会采用一个内存对象指针压缩技术。
在 Java 中,所有的对象都分配在堆上,并通过一个指针进行引用。 普通对象指针(OOP)指向这些对象,通常为 CPU 字长 的大小:32 位或 64 位,取决于你的处理器。指针引用的就是这个 OOP 值的字节位置。
对于 32 位的系统,意味着堆内存大小最大为 4 GB。对于 64 位的系统, 可以使用更大的内存,但是 64 位的指针意味着更大的浪费,因为你的指针本身大了。更糟糕的是, 更大的指针在主内存和各级缓存(例如 LLC,L1 等)之间移动数据的时候,会占用更多的带宽。
Java 使用一个叫作 内存指针压缩(compressed oops)的技术来解决这个问题。 它的指针不再表示对象在内存中的精确位置,而是表示偏移量 。这意味着 32 位的指针可以引用 40 亿个 对象,而不是 40 亿个字节。最终,也就是说堆内存增长到 32 GB 的物理内存,也可以用 32 位的指针表示。
一旦你越过那个神奇的 ~32 GB 的边界,指针就会切回普通对象的指针。 每个对象的指针都变长了,就会使用更多的 CPU 内存带宽,也就是说你实际上失去了更多的内存。事实上,当内存到达 40–50 GB 的时候,有效内存才相当于使用内存对象指针压缩技术时候的 32 GB 内存。
这段描述的意思就是说:即便你有足够的内存,也尽量不要 超过 32 GB。因为它浪费了内存,降低了 CPU 的性能,还要让 GC 应对大内存。
好了,废话了这么多,回归正题,讨论一下如果我们手里有几台很大内存的物理机,怎么搞?
有三个可选项:
* 你主要做全文检索吗?考虑给 Elasticsearch 4~32 GB 的内存, 让 Lucene 通过操作系统文件缓存来利用余下的内存。那些内存都会用来缓存 segments,带来极速的全文检索。
* 你需要更多的排序和聚合?而且大部分的聚合计算是在数字、日期、地理点和 非分词 字符串上?你很幸运,你的聚合计算将在内存友好的 doc values 上完成! 给 Elasticsearch 4~32 GB 的内存,其余部分为操作系统缓存内存中的 doc values。
* 你在对分词字符串做大量的排序和聚合(例如,标签或者 SigTerms,等等)不幸的是,这意味着你需要 fielddata,意味着你需要堆空间。考虑在单个机器上运行两个或多个节点,而不是拥有大量 RAM 的一个节点。仍然要坚持 50% 原则。如果你选择这一种,你需要配置cluster.routing.allocation.same_shard.host: true 。 这会防止同一个分片(shard)的主副本存在同一个物理机上(因为如果存在一个机器上,副本的高可用性就没有了,当某一台物理机宕机时,就会导致某些indices、shards不可用)。
系统环境:centos6.9
运行环境:jdk1.8
准备工作:下载elasticsearch-5.5.3 和 kibana-5.5.3 (为了方便部署,es选择的压缩包部署,kibana直接rpm安装)
1、解压elasticsearch
tar -zxvf elasticsearch-5.5.3.tar.gz
2、配置elasticsearch的第一个实例
mv elasticsearch-5.5.0 elasticsearch-node1
cd elasticsearch-node1/config
备份默认配置文件(个人习惯)
cp elasticsearch.yml elasticsearch.yml.default
cp jvm.options jvm.options.default
配置elasticsearch.yml
cluster.name: mango-es #集群名称
node.name: node-1 #节点名称
node.master: true #节点role
node.data: true #节点role
path.data: ["/opt/data/node-1/es","/opt/data/node-1/es2","/opt/data/node-1/es3"] #es数据路径
path.logs: /opt/logs/es-node1/ #日志路径
bootstrap.memory_lock: true # 设置为true来锁住内存。因为当jvm开始swapping时es的效率会降低,所以要保证它不swap,可以把ES_MIN_MEM和 ES_MAX_MEM两个环境变量设置成同一个值,并且保证机器有足够的内存分配给es。同时也要允许elasticsearch的进程可以锁住内存,linux下可以通过`ulimit -l unlimited`命令。
bootstrap.system_call_filter: false # 具体见后面bootstrap
network.host: 0.0.0.0
http.port: 9200 #监听端口
discovery.zen.ping.unicast.hosts: ["192.168.83.138:9300","192.168.83.138:9301"] # 设置集群中master节点的初始列表,可以通过这些节点来自动发现新加入集群的节点。
discovery.zen.minimum_master_nodes: 1 # 设置这个参数来保证集群中的节点可以知道其它N个有master资格的节点。默认为1,对于大的集群来说,可以设置大一点的值(2-4)
gateway.recover_after_nodes: 1 # 设置集群中N个节点启动时进行数据恢复,默认为1。
# …… 还有一些调优和具体使用情况的具体参数,根据服务器配置和使用场景而变化,这里不做过多配置
配置jvm.options,文中前面大篇幅都在扯这个
-Xms32g
-Xmx32g
启动实例前:
创建es用户,因为es默认是不允许以root用户启动的
useradd elastic
创建相关配置路径,并修改属主
mkdir -p /opt/logs/es-node1
mkdir -p /opt/data/node-1/es
mkdir -p /opt/data/node-1/es2
mkdir -p /opt/data/node-1/es3
chown -R elastic. /opt/logs/es-node1
chown -R elastic. /opt/data/node-1/es
chown -R elastic. /opt/data/node-1/es2
chown -R elastic. /opt/data/node-1/es3
bootstrap相关:
Maximum number of threads check:
修改 /etc/security/limits.conf nproc
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
/etc/security/limits.d/90-nproc.conf
* soft nproc 65535
#大于2048即可
File descriptor check:
ulimit -n 65536
/etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
Heap size check:
elasticsearch.yml
bootstrap.memory_lock: true
bootstrap.memory_lock:
/etc/security/limits.conf
elastic soft memlock unlimited
elastic hard memlock unlimited
system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk:
elasticsearch.yml 在memory下面
bootstrap.system_call_filter: false
max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]:
/etc/sysctl.conf
vm.max_map_count=262144
3、启动第一个实例
nohup su - elastic /opt/apps_install/elk/elasticsearch-node1/bin/elasticsearch &>/dev/null &
4、查看实例状态
curl -s -XGET "http://127.0.0.1:9200/_cat/nodes?v"
同理配置第二个实例即可~复制第一个实例目录,修改配置的数据目录、端口和日志目录,启动即可
5、配置完成后,查看es-cluster状态
curl -s -XGET "http://127.0.0.1:9200/_cluster/health" | jq .
6、配置并启动kibana
/etc/kibana/kibana.yml
server.port: 5601
elasticsearch.url: "http://192.168.83.138:9200"
/etc/rc.d/init.d/kibana start
7、浏览器访问
http://192.168.83.138:5601
8、安装 X-PACK Plugin
什么是X-PACK Plugin?
https://www.elastic.co/products/x-pack
主要是用来查看es集群状态,包括而不限于cpu,memory,nodes,indices,shards等等
情况1:已运行集群,逐台安装x-pack,滚动重启,比较麻烦,等待时间也较长
情况2:位运行集群,关闭es和kibana服务,安装x-pack Plugin,重启服务即可
es安装 x-pack
elasticsearch-plugin install x-pack
配置elasticsearch.yml
action.auto_create_index: .security,.monitoring*,.watches,.triggered_watches,.watcher-history*,.ml*
kibana安装 x-pack
kibana-plugin install x-pack
安装时间较长,请耐心等待
都安装完成后,启动es实例,再启动kibana即可,此时再访问http://192.168.83.138
默认的用户名和密码:elastic changeme
作者:fantasymango
链接:https://www.jianshu.com/p/524b3add02cd
来源:简书
简书著作权归作者所有,任何形式的转载都请联系作者获得授权并注明出处。