文章目录
生产环境部署建议
系统设置要到位
遵照官方建议设置所有的系统参数
参见文档 “setup Elasticsearch =》Important System Configuration”
ES设置尽量简介
- elasticsearch.yml中尽量只写必备的参数,其他可以通过api动态设置的参数都通过api来设定
- 参见文档"Setup Elasticsearch-> Important Elasticsearch Confiquration"
- 随着ES的版本升级,很多网络流传的配置参数已经不再支持,因此不要随便复制别人的集群配置参数
elasticsearch.yml中建议设定的基本参数
- cluster.name
- node.name
- node.master / node.data / node.ingest.
- network.host建议显示指定为内网ip,不要偷懒直接设为0.0.0.0.
- discovery.zen.ping.unicast.hosts设定集群其他节点地址
- discovery.zen.minimum_masternodes一般设定为2
- path.data/path.log
除上述参数外再根据需要增加其他的静态配置参数
动态设定的参数有transient和persistent两种设置,前者在集群重启后会丢失,后者不会,但两种设定都会覆盖elasticsearch.yml中的配置
关于JVM内存设定
- 不要超过31GB
- 预留一半内存给操作系统，用来做文件缓存
- 具体大小根据该node要存储的数据量来估算,为了保证性能,在内存和数据量间有一个建议的比例
----类项目的比例建议在1:16以内
----日志类项目的比例建议在1:48~1:96 - 假设总数据量大小为1TB , 3个node , 1个副本,那么每个node要存储的数据量为2TB/3=666GB ,即700GB左右,做20%的预留空间,每个node要存储大约850GB的数据
----如果是搜索类项目,每个node内存大小为850GB/16=53GB ,大于31GB.31*16=496 ,即每个node最多存储496GB数据,所以需要至少5个node
----如果是日志类型项目,每个node内存大小为850GB/48=18GB,因此3个节点足够
写性能优化
ES写数据-refresh
- segment写入磁盘的过程依然很耗时,可以借助文件系统缓存的特性,先将segment 在缓存中创建并开放查询来进一步提升实时性,该过程在es中被称为refresh.
- 在refresh之前文档会先存储在一个buffer中, refresh时将buffer中的所有文档清空并生成segment
- es默认每1秒执行一次refresh ,因此文档的实时性被提高到1秒,这也是es被称为近实时(Near Real Time)的原因
ES写数据-translog
如果在内存中的segment还没有写入磁盘前发生了宕机,那么其中的文档就无法恢复了,如何解决这个问题?
- es引入translog机制。写入文档到buffer时,同时将该操作写入translog.
- translog文件会即时写入磁盘(fsync) , 6.x默认每个请求都会落盘,可以修改为每5秒写一次,这样风险便是丢失5秒内的数据,相关配置为index.translog.*
- es启动时会检查translog文件,并从中恢复数据
ES写数据-flush
flush负责将内存中的segment写入磁盘,主要做如下的工作:
- 将translog写入磁盘
- 将index buffer清空,其中的文档生成一个新的segment ,相当于一个refresh操作
- 更新commit point并写入磁盘
- 执行fsync操作,将内存中的segment写入磁盘
- 删除旧的translog文件
写性能优化
·目标是增大写吞吐量-EPS(Events Per Second)越高越好
·优化方案
- 客户端:多线程写,批量写
- ES:在高质量数据建模的前提下,主要是在refresh, translog和flush之间做文章
写性能优化-refresh
·目标为降低refresh的频率
- 增大refresh_interval ,降低实时性,以增大一次refresh处理的文档数,默认是 1s,设置为-1直接禁止自动refresh
- 增大index buffer size ,参数为indices.memory.index_buffer _size(静态参数,需要设定在elasticsearch.yml中),默认为10%
写性能优化-translog
目标是降低translog写磁盘的频率,从而提高写效率,但会降低容灾能力
- index.translog.durability设置为async , index.translog.sync_ interval设置需要的大小,比如120s ,那么translog会改为每120s写一次磁盘
- index.translog.flush_threshold_size默认为512mb ,即translog超过该大小时会触发一次flush ,那么调大该大小可以避免flush的发生
写性能优化-flush
目标为降低flush的次数,在6.x可优化的点不多,多为es自动完成
写性能优化-其他
·副本设置为0,写入完毕再增加
·合理地设计shard数,并保证shard均匀地分配在所有node上,充分利用所有node的资源
- index.routing.allocation.total_shards_per_node限定每个索引在每个node上可分配的总主副分片数
- 5个node ,某索引有10个主分片, 1个副本,上述值应该设置为多少?
- (10+10)/5=4
- 实际要设置为5个,防止在某个node下线时,分片迁移失败的问题
·主要为index级别的设置优化,以日志场景举例,一般会有如下的索引设定:
读性能优化
读性能主要受以下几方面影响:
- 数据模型是否符合业务模型?
- 数据规模是否过大?
- 索引配置是否优化?
- 查询语句是否优化?
读性能优化-数据建模
1、高质量的数据建模是优化的基础
- 将需要通过script脚本动态计算的值提前算好作为字段存到文档中
- 尽量使得数据模型贴近业务模型
2、根据不同的数据规模设定不同的SLA
- 上万条数据与上千万条数据性能肯定存在差异
3、索引配置优化主要包括如下:
- 根据数据规模设置合理的主分片数,可以通过测试得到最适合的分片数
- 设置合理的副本数目,不是越多越好
4、查询语句调优主要有以下几种常见手段:
- 尽量使用Filter上下文,减少算分的场景,由于Filter有缓存机制,可以极大提升查询性能
- 尽量不使用Script进行字段计算或者算分排序等
- 结合profile, explain API分析慢查询语句的症结所在,然后再去优化数据模型
如何设定shard数
ES的性能基本是线性扩展的,因此我们只要测出1个Shard的性能指标,然后根据实际性能需求就能算出需要的Shard数。比如单Shard写入eps是10000 ,而线上eps需求是50000 ,那么你需要5个shard, (实际还要考虑副本的情况)
·测试1个Shard的流程如下:
- 搭建与生产环境相同配置的单节点集群
- 设定一个单分片零副本的索引
- 写入实际生产数据进行测试,获取写性能指标
- 针对数据进行查询请求,获取读性能指标
·压测工具可以采用esrally 简书搜=》三步上手esrally
·压测的流程还是比较复杂,可以根据经验来设定。如果是搜索引擎场景,单Shard大小不要超过15GB ,如果是日志场景,单Shard大小不要超过50GB(Shard越大,查询性能, 越低)
·此时只要估算出你索引的总数据大小,然后再除以上面的单Shard大小也可以得到分片数。
xpack监控功能介绍
X-Pack Monitoring
官方推出的免费集群监控功能
安装：bin / elasticsearch-plugin install x-pack
同时kibana也需要安装 bin / kibana-plugin install x-pack
x-pack自带有一个账号机制
- vim config/elasticsearch 进入此文件关闭；登录kibana就不会有密码账号了
进入kibana中的Monitoring功能