ElasticSearch注意点

56 阅读 0 评论 37 点赞

我是靠谱客的博主迷你心锁，最近开发中收集的这篇文章主要介绍ElasticSearch注意点，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

文章引用 http://baijiahao.baidu.com/s?id=1582140418694970203&wfr=spider&for=pc

自我Mark下

三个层面来讲：第一个有关Linux的系统配置，第二是集群层面的参数设置，最后会涉及到存储到集群上的索引设置。

1、OS参数设置

像OS这个参数设置，首先提到的是内存相关的参数，由于ES采用Mapping机制，将文件映射到内存，在系统级别有一些相关的参数要设置。另一个就是文件数，假设我们所有都设置到最大65535。

这个设置之后还需要在下面加入加入login这个文件，这里讲得非常具体，可以说是一个教程。

这里我只是做了一个示例，在Ext4文件系统中，每一次访问一个文件或者目录时，其实OS级别会记录访问时间，如果只是在海量文件的情况，上述的记录信息就会对IO有影响。有一篇文章提到，关闭文件访问时间信息之后，系统IO性能可以提升20%—30%。

我们知道Linux里面文件信息，不是直接改一次之后就写入到磁盘，它会先有一个文件的缓存，文件的缓存什么情况下会被写入到disk里面？有两个相应的系统参数可以设置的，一个是vm.dirty_background_ratio，一个是vm.dirty_ratio，一旦缓存占据内存超过百分比（默认值是20%）之后，内核就停止其它方面的操作，而只做文件的缓存吐到disk的操作，这时效果有点像Java里进行垃圾回收一样，对外界停止响应。 vm.dirty_ratio就是当它缓存量达到20%时，它就其它的什么都不干了，只做数据同步到disk一件。

内存不够时，会使用swap空间，内存很大的话，可以不用创建swap空间。默认值是60，但是我们把它设置为零的话，是跟swap off效果一样。但为了避免内核出现OOM，只是将其设置为1。

2、ElasticSearch参数设置

刚才两个讲的都是系统级别的设置，一个是内存，另一个是系统级别的IO，下面讲的是针对ES—JVM的设置。

这里建议，不管物理内存有多大，分配给Elasticsearch的只设成32G，同时后面如果出现OOM，进程直接退出。

为什么说要把它改成这个呢？因为我们在使用一个集群时看到，有时因为聚合操作的原因，会导致某一台机器上的JAVA进程出现OOM，但是这个JVM进程还在，并没有退出，退出的话可以通过monit捕捉到，也可以进行重启。如果没有退出，而是一直挂在那的话，就不能提供正常的服务。此外加上这个参数的话，需要升级一下JDK版本，JDK要求1.8.0_92, 从这个版本开始支持ExitOnOutOfMemoryError参数。

另外一种办法就是如果我们内存不能升级JDK、存在种种现实约束的话，可以在这个时候用另一种方式来实现，在JVM启动参数中加入

-XX:OnOutOfMemoryError="kill -9 %p"。

这里就是讲输入到ElasticSearch里面每个集群的一些参数，一些相对比较主要的一些参数。这里的参数配了一幅图，这幅图最想表明的意思是说，我的参数的配置要使得我从整个集群的角度上来看，它每一台机器上的shard数目基本是相当的。

这里有一点，参数设置能保证shard数目是基本相当的，但并不是保证每一个shard的大小相等，这两者还是有差异的。决定每个集群上shard相等的参数是由这个balance决定，它默认一个是0.5，把它往下调的话，就不可以倾斜；往上调的话对倾斜的容忍度相对比较高。

ElasticSearch是一个高可靠的系统，集群的一个节点挂掉了，另一个节点是可以继续的。挂掉的节点是进行恢复，为了避免恢复工作对集群造成太多影响，主要是避免大的I/O消耗，需要进行参数设置。比如集群中同时在进行恢复的索引可以是多少个，还有就是一个node上能允许shard在做恢复。这两个参数是cluster_concurrent_rebalance和node_concurrent_recoveries。

如果要缩容、对某一台机器进行维护、将其从集群中拉出来该怎么办？这个时候可以设定exclude名单，名单可以通过ip地址或主机名来指定。一旦设置的exlude名单，该名单上节点中的索引数据被拉到别的机器上面，数据被拉完之后，就可以被这个集群拉出去的机器进行维护，避免维护带来的数据丢失。

3、索引参数设置

这是具体到一个索引参数的设置。在讲具体参数之前，我们可以先讲一下ElasticSearch索引参数的设置、输入以及中间发生的过程。当真正的数据请求到达ElasticSearch节点之后，它一方面会写入到内存中，另外一部分会写入到TransactionLog。

写入到内存并不意味着可以被搜索，要通过Refresh操作，才可以被搜索到。Refresh之后，数据可以被搜索到，此刻数据还在内存中，如果很不巧的话，在这个时候断电，或者出现其它故障不可用了，那么等到这台机器再恢复时，我刚才写的内容就丢失掉了，因为并没有被持久化到磁盘。为了持久化这个内容，需要进行一次FLUSH操作， flush的内容会被写到一个segment中。可想而知，随着时间的推移，系统会产生大量的segments，这些segment需要把它合并成一个大的。不合并成一个大的会怎样呢？不合并成一个大的，就是说每一个segment都会吃掉一些文件句柄，文件句柄数是有限的。另一个带来的就是查询性能下降，因为查询的时候，要对所有segments进行访问，效率就比较低了。

有了刚才讲的三步之后，再来看下面的参数就比较容易好理解了。 Refresh_interval 过多久可以让你查询到，时间越短就可以被越快地检索到，但是意味着我相应的I/O也上去了，在有大批量数据导入时，这个数值会适当的调大。

在我们目前部署的集群中，高峰时候每秒写入量，有十几万。为了应对这种场景，将refresh_interval设置为100多秒或者90秒以上。

Number_of_shards索引分片的数目，这个数目可以设置得大一些，还有每一个分片的副本，在大批量导入时，由于副本数目是可以动态调整的，副本数也可以先设置为零，等数据全部导入后，再设置为非0值。副本数可以动态调整，但是分片数目是无法动态调整的，也就是说，除非重建另外一个索引，不然原先设置的是啥样就只能啥样。这个FLUSH也可以调大，需要的时候可以设置得大一些。

下面就是做segments合并的线程数，如果是spin disk的话，就使用默认值1，如果是SSD的话，可以把它调大一些。讲到SSD代码的话，为了进一步优化性能，可以将系统的i/o scheduler设置为noop 。