升级硬件
如果索引是受I ／ O约束的，则应研究为文件系统高速缓存提供更多内存（请参见上文）或购买速度更快的驱动器。特别是，已知SSD驱动器的性能要比旋转磁盘好。始终使用本地存储，应避免使用NFS或SMB等远程文件系统。还请注意虚拟存储，例如Amazon的Elastic Block Storage。虚拟存储在Elasticsearch上可以很好地工作，并且很有吸引力，因为它安装起来如此之快且简单，但是与专用本地存储相比，它在本质上在持续运行方面还很慢。如果在EBS上建立索引，请确保使用预配置的IOPS，否则操作可能会很快受到限制。
通过配置RAID 0阵列，跨多个SSD划分索引。请记住，由于任何一个SSD的故障都会破坏索引，因此会增加故障的风险。但是，通常这是一个正确的权衡：优化单个分片以实现最佳性能，然后在不同节点之间添加副本，以便为任何节点故障提供冗余。您还可以使用快照和还原来备份索引以提供进一步保障。
优化磁盘间的任务均匀情况，将shard尽量均匀分布到物理主机的各个磁盘。
如果部署方案是为path．data配置多个路径来使用多块磁盘，则ES在分配shard时，落到各磁盘上的 shard 可能并不均匀，这种不均匀可能会导致某些磁盘繁忙，利用率在较长时间内持续达到100％。这种不均匀达到一定程度会对写入性能产生负面影响。ES在处理多路径时，优先将shard分配到可用空间百分比最多的磁盘上，因此短时间内创建的shard可能被集中分配到这个磁盘上，即使可用空间是99％和98％的差别。后来ES在2．x版本中开始解决这个问题：预估一下shard 会使用的空间，从磁盘可用空间中减去这部分，直到现在6．x版也是这种处理方式。但是实现也存在一些问题：
从可用空间减去预估大小这种机制只存在于一次索引创建的过程中，下一次的索引创建，磁盘可用空间并不是上次做完减法以后的结果。这也可以理解，毕竟预估是不准的，一直减下去空间很快就减没了。但是最终的效果是，这种机制并没有从根本上解决问题，即使没有完美的解决方案，这种机制的效果也不够好。如果单一的机制不能解决所有的场景，那么至少应该为不同场景准备多种选择。为此，我们为ES增加了两种策略。·
简单轮询：在系统初始阶段，简单轮询的效果是最均匀的。·
基于可用空间的动态加权轮询：以可用空间作为权重，在磁盘之间加权轮询。
您应该通过禁用交换来确保操作系统不会交换出Java进程。
大多数操作系统尝试为文件系统高速缓存使用尽可能多的内存，并急切换出未使用的应用程序内存。这可能会导致部分JVM堆甚至其可执行页面换出到磁盘上。
交换对性能，节点稳定性非常不利，应不惜一切代价避免交换。它可能导致垃圾收集持续数分钟而不是毫秒，并且可能导致节点响应缓慢甚至断开与集群的连接。在弹性分布式系统中，让操作系统杀死该节点更为有效。
文件系统缓存将用于缓冲I ／ O操作。您应确保至少将运行Elasticsearch的计算机的一半内存分配给文件系统缓存。
首页
