硬盘对集群非常重要，特别是建索引多的情况。磁盘是一个服务器最慢的系统，对于写比较重的集群，磁盘很容易成为集群的瓶颈。
如果可以承担的器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
未完待续
你可能还会喜欢
