从 10 秒到 2 秒！ElasticSearch 性能调优

ElasticSearch性能调优

大家好，我是皮蛋二哥。

“ELK”是ElasticSearch、Logstash、Kibana三门技术的简称。如今ELK技术栈在互联网行业数据开发领域使用率越来越高，做过数据收集、数据开发、数据存储的同学相信对这个简称并不陌生，而ElasticSearch（以下简称ES）则在ELK栈中占着举足轻重的地位。

前一段时间，我亲身参与了一个ES集群的调优，今天把我所了解与用到的调优方法与大家分享，如有错误，请大家包涵与指正。

系统层面的调优

系统层面的调优主要是内存的设定与避免交换内存。

ES安装后默认设置的堆内存是1GB，这很明显是不够的，那么接下来就会有一个问题出现：我们要设置多少内存给ES呢？

其实这是要看我们集群节点的内存大小，还取决于我们是否在服务器节点上还是否要部署其他服务。

如果内存相对很大，如64G及以上，并且我们不在ES集群上部署其他服务，那么我建议ES内存可以设置为31G-32G，因为这里有一个32G性能瓶颈问题，直白的说就是即使你给了ES集群大于32G的内存，其性能也不一定会更加优良，甚至会不如设置为31G-32G时候的性能。

以我调优的集群为例，我所调优的服务器节点内存为64G，服务器节点上也基本不跑其他服务，所以我把ES集群内存大小设置为了31G，以充分发挥集群性能。 设置ES集群内存的时候，还有一点就是确保堆内存小值（Xms）与大值（Xmx）的大小是相同的，防止程序在运行时改变堆内存大小，这是一个很耗系统资源的过程。

还有一点就是避免交换内存，可以在配置文件中对内存进行锁定，以避免交换内存（也可以在操作系统层面进行关闭内存交换）。对应的参数： bootstrap.mlockall: true

分片与副本

分片(shard):ES是一个分布式的搜索引擎, 索引通常都会分解成不同部分, 分布在不同节点的部分数据就是分片。ES自动管理和组织分片, 并在必要的时候对分片数据进行再平衡分配, 所以用户基本上不用担心分片的处理细节。创建索引时默认的分片数为5个，并且一旦创建不能更改。

副本(replica):ES默认创建一份副本，就是说在5个主分片的基础上，每个主分片都相应的有一个副本分片。额外的副本有利有弊，有副本可以有更强的故障恢复能力，但也占了相应副本倍数的磁盘空间。

那我们在创建索引的时候，应该创建多少个分片与副本数呢？

对于副本数，比较好确定，可以根据我们集群节点的多少与我们的存储空间决定，我们的集群服务器多，并且有足够大多存储空间，可以多设置副本数，一般是1-3个副本数，如果集群服务器相对较少并且存储空间没有那么宽松，则可以只设定一份副本以保证容灾（副本数可以动态调整）。

对于分片数，是比较难确定的。因为一个索引分片数一旦确定，就不能更改，所以我们在创建索引前，要充分的考虑到，以后我们创建的索引所存储的数据量，否则创建了不合适的分片数，会对我们的性能造成很大的影响。 对于分片数的大小，业界一致认为分片数的多少与内存挂钩，认为1GB堆内存对应20-25个分片，而一个分片的大小不要超过50G，这样的配置有助于集群的健康。但是我个人认为这样的配置方法过于死板，我个人在调优ES集群的过程中，根据总数据量的大小，设定了相应的分片，保证每一个分片的大小没有超过50G（大概在40G左右），但是相比之前的分片数查询起来，效果并不明显。之后又尝试了增加分片数，发现分片数增多之后，查询速度有了明显的提升，每一个分片的数据量控制在10G左右。 查询大量小分片使得每个分片处理数据速度更快了，那是不是分片数越多，我们的查询就越快，ES性能就越好呢？其实也不是，因为在查询过程中，有一个分片合并的过程，如果分片数不断的增加，合并的时间则会增加，而且随着更多的任务需要按顺序排队和处理，更多的小分片不一定要比查询较小数量的更大的分片更快。如果有多个并发查询，则有很多小碎片也会降低查询吞吐量。

如果现在你的场景是分片数不合适了，但是又不知道如何调整，那么有一个好的解决方法就是按照时间创建索引，然后进行通配查询。如果每天的数据量很大，则可以按天创建索引，如果是一个月积累起来导致数据量很大，则可以一个月创建一个索引。如果要对现有索引进行重新分片，则需要重建索引，我会在文章的后总结重建索引的过程。

参数调优

下面我会介绍一些ES关键参数的调优。

有很多场景是，我们的ES集群占用了多大的cpu使用率，该如何调节呢。cpu使用率高，有可能是写入导致的，也有可能是查询导致的，那要怎么查看呢？ 可以先通过GET _nodes/{node}/hot_threads查看线程栈，查看是哪个线程占用cpu高，如果是elasticsearch[{node}][search][T#10]则是查询导致的，如果是elasticsearch[{node}][bulk][T#1]则是数据写入导致的。 我在实际调优中，cpu使用率很高，如果不是SSD，建议把index.merge.scheduler.max_thread_count: 1 索引merge大线程数设置为1个，该参数可以有效调节写入的性能。因为在存储介质上并发写，由于寻址的原因，写入性能不会提升，只会降低。

还有几个重要参数可以进行设置，各位同学可以视自己的集群情况与数据情况而定。

index.refresh_interval：这个参数的意思是数据写入后几秒可以被搜索到，默认是1s。每次索引的refresh会产生一个新的lucene段,这会导致频繁的合并行为，如果业务需求对实时性要求没那么高，可以将此参数调大，实际调优告诉我，该参数确实很给力，cpu使用率直线下降。

indices.memory.index_buffer_size：如果我们要进行非常重的高并发写入操作，那么好将indices.memory.index_buffer_size调大一些，index buffer的大小是所有的shard公用的，一般建议（看的大牛博客），对于每个shard来说，多给512mb，因为再大性能就没什么提升了。ES会将这个设置作为每个shard共享的index buffer，那些特别活跃的shard会更多的使用这个buffer。默认这个参数的值是10%，也就是jvm heap的10%。

translog：ES为了保证数据不丢失，每次index、bulk、delete、update完成的时候，一定会触发刷新translog到磁盘上。在提高数据安全性的同时当然也降低了一点性能。如果你不在意这点可能性，还是希望性能优先，可以设置如下参数：

"index.translog": {
            "sync_interval": "120s",     --sync间隔调高
            "durability": "async",       -– 异步更新
            "flush_threshold_size":"1g"  --log文件大小
        }