以下主要来自官方文档,主要分为几块:
硬件方面
内存
首先最重要的资源是内存,排序和聚合都可能导致内存匮乏,因此足够的堆空间来容纳这些是重要的。即使堆比较小,也要给操作系统高速缓存提供额外的内存,因为Lucene使用的许多数据结构是基于磁盘的格式,Elasticsearch利用操作系统缓存有很大的影响。
64GB RAM的机器是最理想的,但32GB和16GB机器也很常见。少于8GB往往适得其反(你最终需要许多,许多小机器),大于64GB可能会有问题,我们将在讨论在堆:大小和交换。
CPU
大多数Elasticsearch部署往往对CPU要求很不大。因此,确切的处理器设置比其他资源更重要,应该选择具有多个内核的现代处理器。通用集群使用2到8核机器。
如果需要在较快的CPU或更多核之间进行选择,请选择更多核。 多核提供的额外并发将远远超过稍快的时钟速度。
硬盘
磁盘对于所有集群都很重要,尤其是对于索引很重的集群(例如摄取日志数据的磁盘)。 磁盘是服务器中最慢的子系统,这意味着大量写入的群集可以轻松地饱和其磁盘,这反过来成为群集的瓶颈。
如果你能买得起SSD,他们远远优于任何旋转磁盘。 支持SSD的节点看到查询和索引性能方面的提升。
如果使用旋转磁盘,请尝试获取尽可能最快的磁盘(高性能服务器磁盘,15k转速驱动器)。
使用RAID 0是提高磁盘速度的有效方法,适用于旋转磁盘和SSD。 没有必要使用RAID的镜像或奇偶校验变体,因为高可用性是通过副本建立到Elasticsearch中。
最后,避免网络连接存储(NAS)。 NAS通常较慢,显示较大的延迟,平均延迟的偏差较大,并且是单点故障。
检查IO调度程序
如果使用SSD,请确保正确配置您的OS I/O调度程序。 当将数据写入磁盘时,I/O调度程序将确定该数据何时实际发送到磁盘。 大多数调度的默认值是名为cfq(Completely Fair Queuing)。
此调度程序为每个进程分配时间片,然后优化这些不同队列到磁盘的传递。 他是针对旋转磁盘介质的优化:旋转盘的性质意味着根据物理布局将数据写入磁盘更高效。
然而,这对于SSD是低效的,因为SSD不涉及磁盘旋转。 相反,应该使用deadline或noop。 deadline调度根据写入已经等待的时间进行优化,noop只是一个简单的FIFO队列。
这种简单的变化可以产生巨大的影响 我们已经看到,通过使用正确的调度程序,写入吞吐量提高了500倍。cat /sys/block/sda/queue/scheduler命令查看,修改参照http://www.nuodb.com/techblog/tuning-linux-io-scheduler-ssds
网络
快速和可靠的网络对于分布式系统中的性能显然是重要的。低延迟有助于确保节点可以轻松地进行通信,而高带宽有助于分段移动和恢复。现代数据中心网络(1GbE,10GbE)对于绝大多数集群都是足够的。
避免跨越多个数据中心的群集,即使数据中心位置非常接近。绝对避免跨越大地理距离的集群。
Elasticsearch集群假定所有节点相等,而不是一半的节点距离另一个数据中心中有150ms。较大的延迟往往会加剧分布式系统中的问题,并使调试和解决更加困难。
与NAS参数类似,每个人都声称数据中心之间的管道是稳健的和低延迟。(吹牛)。从我们的经验,管理跨数据中心集群的麻烦就是浪费成本。
其他
现在可以获得真正巨大的机器如数百GB的RAM和几十个CPU内核。 另外也可以在云平台(如EC2)中启动数千个小型虚拟机。 哪种方法最好?
一般来说,最好选择中到大盒子。 避免使用小型机器,因为您不想管理具有一千个节点的集群,而简单运行Elasticsearch的开销在这种小型机器上更为明显。
同时,避免真正巨大的机器。 它们通常导致资源使用不平衡(例如,所有内存正在使用,但没有CPU),并且如果您必须为每台机器运行多个节点,可能会增加后期的运维复杂性。
操作系统
较大的文件描述符
Lucene使用了非常大量的文件。 并且Elasticsearch使用大量的套接字在节点和HTTP客户端之间进行通信。 所有这些都需要可用的文件描述符。
可悲的是,许多现代的Linux发行版每个进程允许一个不允许的1024个文件描述符。 这对于一个小的Elasticsearch节点来说太低了,更不用说处理数百个索引的节点了。
您应该将文件描述符计数增加到非常大的值,例如64,000。 这个过程是令人恼火的困难,高度依赖于你的特定操作系统和分布。 请查阅操作系统的文档以确定如何更改允许的文件描述符计数。
可以使用http://ip:port/_nodes/stats接口process中的open_file_descriptors和max_file_descriptors进行查看。