**背景:**数据进入到Elasticsearch当中之后,如何才能让数据被更快的检索使用,用一句话概括就是"开新文件",但是每一秒都在打开新文件,一天有86400秒,设想一下,每次请求都要扫描86400个文件,这个性能肯定好不了。
归并线程
segment归并的过程,需要先读取segment,归并计算,再写一遍segment,最后刷到磁盘。这是一个非常消耗磁盘和IO的任务,所以我们需要对归并线程进行限速,默认配置是20MB,这对于写入量大,磁盘转速高,这个配置明显是过低的,所以我们需要提高限速。
bash
# curl -XPuT http://127.0.0.1:9200/cluster/settings -d'
"persistent":{
"indices.store.throttle.maxbytes per sec":"100mb"
归并策略
归并线程是按照一定的运行策略来挑选segment 进行归并的主要为以下几条:
- index.merge.policy.floor_segment 默认 2MB,小于这个大小的 segment,优先被归并
- index.merge.policy.max merge at once 默认一次最多归并10个segment。
- index.merge.policy.max merge _at once_explicit 默认 forcemerge 时一次最多归并 30个segment.
- index.merge.policy.max_merged segment默认5 GB,大于这个大小的segment,不用参与归并。optimize 除外。
shard的allocate控制
以下几种情况会触发分配动作:
- 新索引生成
- 索引的删除。
- 新增副本分片
- 节点增减引发的数据均衡。
Elasticsearch 提供了一系列参数详细控制这部分逻辑:
- cluster.routing.allocation.enable 参数用来控制允许分配哪种分片。默认是 all。可选项还包括 primaries和new_primaries。none 则彻底拒绝分片。
- cluster.routing.allocation.allow rebalance 参数用来控制什么时候允许数据均衡。默认是indicesall active,即要求所有分片都正常启动成功以后,才可以进行数据均衡操作,否则的话,在集群重启阶段,会浪费太多流量了。
- cluster.routing.allocation.cluster concurrent rebalance参数用来控制集群内同时运行的数据均衡任务个数。默认是2个。如果有节点增减,且集群负载压力不高的时候可以适当加大。
- cluster.routing.allocation.node initial primaries recoveries参数用来控制节点重启时允许同时恢复几个主分片。默认是4个。如果节点是多磁盘,且I0压力不大,可以适当加大。
- cluster.routing.allocation.node concurrent recoveries参数用来控制节点除了主分片重启恢复以外其他情况下,允许同时运行的数据恢复任务。默认是2个。所以,节点重启时可以看到主分片迅速恢复完成,副本分片的恢复却很慢。除了副本分片本身数据要通过网络复制以外,并发线程本身也减少了一半。当然,主分片一定是本地恢复,副本分片却需要走网络,带宽是有限的。
- indices.recovery.concurrent streams参数**用来控制节点从网络复制恢复副本分片时的数据流个数。**默认是3个。
- indices.recovery.max_bytes_per _sec参数用来控制节点恢复时的速率。默认是 40MB。也可根据上面配置加大
分片分配控制策略
磁盘限额 --为了保护节点数据安全,Elasticsearch会定时(cluster.info.update.interval,默认 30秒)检查一下各节点的数据目录磁盘使用情况。
在达到clusterrouting.allocation.disk.watermark.low(默认85%) 的时候,新索引分片就不会再分配到这个节点上了。在达到**cluster.routing.allocation.disk.watermark.high(默认 90%)**的时候,就会触发该节点现存分片的数据均衡,把数据挪到其他节点上去。这两个值不但可以写百分比,还可以写具体的字节数。出于成本考虑,对磁盘使用率有一定的要求,需要适当抬高这个配置:
bash
# curl-XPuT localhost:9200/cluster/settings -d'{"transient":{
"cluster,routing.allocation.disk.watermark.low""85%"
"cluster.routing.allocation.disk.watermark.high":"10qb"
"cluster.info.update.interval":"1m"
热索引分片不均--默认情况下,Elasticsearch集群的数据均衡策略是以各节点的分片总数(indicesall active)作为基准的。这对于搜索服务来说无疑是均衡搜索压力提高性能的好办法。但是对于ELKstack场景,一般压力集中在新索引的数据写入方面。正常运行的时候,也没有问题。但是当集群扩容时,新加入集群的节点,分片总数远远低于其他节点。这时候如果有新索引创建,Elasticsearch的默认策略会导致新索引的所有主分片几乎全分配在这台新节点上。整个集群的写人压力,压在一个节点上,结果很可能是这个节点直接被压死,集群出现异常。所以,对于ELKstack场景,建议预先计算好索引的分片数后,配置好单节点分片的限额。比如,一个5节点的集群,索引主分片10个,副本1份。则平均下来每个节点应该有4个分片,那么就配置:
bash
#curl-s-XPuT http://127.0.0.1:9200/logstash-2015.05.08/ settings -d '{"index":{"routing.allocation.total shards per node" :"5"
注意,这里配置的是5而不是4。因为我们需要预防有机器故障,分片发生迁移的情况如果写的是4,那么分片迁移会失败。
- cluster.routing.allocation.balance.shard节点上分配分片的权重,默认值为 0.45。数值越大越倾向于在节点层面均衡分片。
- cluster.routing.allocation.balance.index每个索引往单个节点上分配分片的权重,默认值为0.55。数值越大越倾向于在索引层面均衡分片。
- cluster.routing.allocation.balance.threshold 大于阈值则触发均衡操作。默认值为1。