本帖最后由 PeersLee 于 2016-9-20 15:32 编辑
问题导读:
1.机器如何设置(硬盘、CPU)?
2.索引过程是什么?
解决方案:
机器设置(硬盘、CPU)
硬盘对集群非常重要,特别是建索引多的情况。磁盘是一个服务器最慢的系统,对于写比较重的集群,磁盘很容易成为集群的瓶颈。
如果可以承担的器SSD盘,最好使用SSD盘。如果使用SSD,最好调整I/O调度算法。RAID0是加快速度的不错方法。
ES建议机器配置:64G内存 SSD硬盘 RAID0,不要使用NAS。
自动调整存储带宽
在2.0.0之前,elasticsearch会限制合并速度(merges),默认为20MB/sec。但是这个速率经常是显得太小,导致合并速度落后于索引速度,进而限制了索引速度。
现在Elasticsearch2.0.0,使用了自动调整合并IO速度方式:如果合并落于索引速度,合并IO速度会逐渐增大,并且随着合并的持续进行会减小。在索引吞吐量小的时候,即使突然来了一个大的合并任务,这种情况也不会吞噬整个节点可用的IO,极小化的降低对正在进行的查询和索引的影响。
但是对索引请求大的情况下,允许的合并速度会自动调整到跟上索引的速度。
有了2.0.0这个特性,意味着我们不需要管任何的限制值了,只要用默认的就好了。
2.0.0之前store throttle 设置值有如下几个,在2.0.0版本已经删除了。
[mw_shl_code=scala,true]indices.store.throttle.type,
indices.store.throttle.max_bytes_per_sec,
index.store.throttle.type,
index.store.throttle.max_bytes_per_sec
[/mw_shl_code]
另外,Recovery/snapshot/restore 仍然是有速度限制的,默认都是20MB/sec。
多个path.data 路径
如果磁盘空间和IO性能是Elasticsearch的瓶颈的话,使用多个IO设备(通过设置多个path.data路径)存储shards,能够增加总的存储空间和提升IO性能。
在Elasticsearch2.0之前的版本,也是配置多个path.data路径,但是其相当于RAID 0,每个shards的数据会分布在所有的磁盘上。当一个节点上有一块盘坏了的情况下,该节点上所有的shards都会损坏了。需要恢复该节点上的所有shards。
在2.0.0版本,把这个实现改成了:每个shards所有的数据只会在一块磁盘上面。这样即使一个节点的一块磁盘损坏了,也只是损失了该磁盘上的shards,其它磁盘上的shards安然无事。只需要恢复该块盘上的shards即可。
升级到2.0.0版本时,旧版本一个shard分布到所有磁盘上的数据,会拷贝到一块盘上。
对应这个改变,在设计shards时,如果一个节点有10块磁盘,共3个节点,则shards至少30个,才能分布在30块盘上(即最大限度使用磁盘空间)。
参考
https://www.elastic.co/blog/performance-indexing-2.0
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
CPU(threadpool)
线程不是越大越好,一般设置threadpool数为CPU cores的个数
搜索:int((# of cores * 3) / 2) + 1
ElastiSearch服务器有多个线程池大小配置。主要有:index,search,suggest,get,bulk,percolate,snapshot,snapshot_data,warmer,refresh。
在此主要针对index和search进行一个配置调整。index操作包含:创 建/更新/删除索引数据。search操作主要针对用户的各种搜索操作。
具体配置如下:
[mw_shl_code=scala,true]threadpool:
index:
type: fixed
size: 100
search:
type: fixed
size: 1000[/mw_shl_code]
参考文档
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
索引过程
大家可能会遇到索引数据比较慢的过程。其实明白索引的原理就可以有针对性的进行优化。ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡。所以从上我可以通过索引的settings进行第一优化:
“index.translog.flush_threshold_ops”:”10000”
这两个参数第一是到translog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的。所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行translog平衡。第二参数是刷新频率,默认为120s是指索引在生命周期内定时刷新,一但有数据进来能refresh像lucene里面commit,我们知道当数据addDoucment后,还不能检索到要commit之后才能行数据的检索,所以可以将其关闭,在最初索引完后手动refresh一之,然后将索引setting里面的index.refresh_interval参数按需求进行修改,从而可以提高索引过程效率。
另外的知道ES索引过程中如果有副本存在,数据也会马上同步到副本中去。我个人建议在索引过程中将副本数设为0,待索引完成后将副本数按需量改回来,这样也可以提高索引效率。
“number_of_replicas”: 0
其实检索速度快度与索引质量有很大的关系。而索引质量的好坏主要与以下几方面有关:
分片数
分片数是与检索速度非常相关的的指标,如果分片数过少或过多都会导致检索比较慢。分片数过多会导致检索时打开比较多的文件别外也会导致多台服务器之间通讯。而分片数过少会导致单个分片索引过大,所以检索速度慢。基于索引分片数=数据总量/单分片数的计算公式,在确定分片数之前需要进行单服务单索引单分片的测试,目前我们测试的结果单个分片的内容为10G。
分片(Shard):一个索引会分成多个分片存储,分片数量在索引建立后不可更改,推荐【分片数*副本数=集群数量】
确定分片(shard)的数量和副本(replica)的数量ElasticSearch在创建索引数据时,最好指定相关的shards数量和replicas, 否则会使用服务器中的默认配置参数shards=5,replicas=1。
因为这两个属性的设置直接影响集群中索引和搜索操作的执行。假设你有足够的机器来持有碎片和副本,那么可以按如下规则设置这两个值:
1) 拥有更多的碎片可以提升索引执行能力,并允许通过机器分发一个大型的索引;
2) 拥有更多的副本能够提升搜索执行能力以及集群能力。
对于一个索引来说,number_of_shards只能设置一次,而number_of_replicas可以使用索引更新设置API在任何时候被增加或者减少。
这两个配置参数在配置文件的配置如下:
index.number_of_shards: 5 number_of_replicas: 1
Elastic官方文档建议:一个Node中一个索引最好不要多于三个shards.配置total_shards_per_node参数,限制每个index每个节点最多分配多少个发片.
http://www.open-open.com/doc/view/f240d61f8f7745098b4459c2483feb40
http://wenku.baidu.com/link?url=bwD9mpebmQ28mqPj6Z0P1_A9bgFKnhIss8UrRA_Nsv7oTFuUEa9JgUdr9ynKc8OjWvd0pVLsp3tYZTFaNcxVt30EyFBCvkNflFGjMWcqsRq
副本数
副本数与索引的稳定性有比较大的关系,如果Node在非正常挂了,经常会导致分片丢失,为了保证这些数据的完整性,可以通过副本来解决这个问题。建议在建完索引后在执行Optimize后,马上将副本数调整过来。
分词
分词对于索引的影响可大可小,看自己把握。大家或许认为词库越多,分词效果越好,索引质量越好,其实不然。分词有很多算法,大部分基于词表进行分词。也就是说词表的大小决定索引大小。所以分词与索引膨涨率有直接关系。词表不应很多,而对文档相关特征性较强的即可。比如论文的数据进行建索引,分词的词表与论文的特征越相似,词表数量越小,在保证查全查准的情况下,索引的大小可以减少很多。索引大小减少了,那么检索速度也就提高了。
索引段
索引段即lucene中的segments概念,我们知道ES索引过程中会refresh和tranlog也就是说我们在索引过程中segments number不只一个。而segments number与检索是有直接联系的,segments number越多检索越慢,而将segments numbers 有可能的情况下保证为1,这将可以提高将近一半的检索速度。
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
上一篇
ElasticSearch优化技巧总结2
转自:简书
作者:jacksu在简书
|
|