ElasticSearch优化系列五:机器设置(硬盘、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版本已经删除了。

indices.store.throttle.type, 
indices.store.throttle.max_bytes_per_sec, 
index.store.throttle.type, 
index.store.throttle.max_bytes_per_sec

另外,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操作主要针对用户的各种搜索操作。
具体配置如下:

threadpool:
    index:
        type: fixed
        size: 100
    search:
        type: fixed
        size: 1000

参考文档
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html

未完待续

你可能还会喜欢

推荐阅读更多精彩内容