Elasticsearch经验总结（持续补充）

Posted 2023-02-23 woshiaotian

重要
我的博客从今天起开始陆续迁移到
http://vearne.cc
敬请关注
本文新地址
http://vearne.cc/archives/65

起因：

ES在笔者所在的公司使用也有3年多了，集群的规模达到上百台，期间也有很多的经验，我这里总结出来分享给大家，技术水平有限，如有错误请指正。

事项：

这些事项，我把它们以问题的形式列出，并会持续补充

1. 关于shard大小的分配

ES的shard是在index创建好时，就已经分配了，所以shard数量的选择非常重要，根据经验shard的大小在10GB ~ 20GB 较为合适。选择这个大小的原因如下
1）ES是通过移动shard来实现负载均衡，如果shard过大移动会非常缓慢
2）另外每个shard相当于一个lucene实例，lucene实例也对应着一组Java线程，所以shard数也不应该过多

2. 关于index的命名设计

如果数据是随着时间增长的，可以选择按月，或者按天分库
index的命名可以是
index_201701、index_201702、index_201703
或
index_20170301、index_20170302、index_20170303
然后可以为他们指定别名index_2017，这样可以直接使用这个别名查询所有index库
另外ES的库是可以关闭的，关闭以后，不占内存空间，只消耗硬盘空间

3. SSD OR 机械硬盘？

Elasticsearch的速度有赖于索引，大量的索引是以文件的形式存储在硬盘上的，如果你的数据量较大，且单次的查询或聚合量较大，那么应该使用SSD，据我们的测试表明，再查询的数据量较大的情况下，
使用SSD的ES速度是机械硬盘的ES速度的10倍， 官方说法在正确配置的情况下，SSD的写入速度是机械硬盘的500倍

给一个参考值
数据单条记录1kB
操作系统Centos 6.7
内存64G
ES版本2.3 ，堆内存31GB
单个ES data node处理能力

机械硬盘	SSD
1w/min	10w/min

见参考资料[1]

If you are using SSDs, make sure your OS I/O scheduler is configured correctly. When you write data to disk, the I/O scheduler decides when that data is actually sent to the disk. The default under most *nix distributions is a scheduler called cfq (Completely Fair Queuing).

This scheduler allocates time slices to each process, and then optimizes the delivery of these various queues to the disk. It is optimized for spinning media: the nature of rotating platters means it is more efficient to write data to disk based on physical layout.

This is inefficient for SSD, however, since there are no spinning platters involved. Instead, deadline or noop should be used instead. The deadline scheduler optimizes based on how long writes have been pending, while noop is just a simple FIFO queue.

This simple change can have dramatic impacts. We’ve seen a 500-fold improvement to write throughput just by using the correct scheduler.

4. 版本问题

请确保Java版本在1.8以上，ES 5.x 比早期的版本性能有较大提升。

5. ES实例的 堆大小的设定

ES的官方建议是将内存的一半大小作为ES的堆大小，并且对内存大小不要超过32GB（实际只能到31GB左右）。
对于32GB的内存而言，只需要32-bits的指针，而对内存再大的话，就需要更长的指针。官方说法31GB的效果相当于40GB的效果
对于大内存的机器，可以部署多个ES实例。

实践经验表明，64GB内存的机器，ES实例堆的大小可以设到31GB左右，96GB内存的机器，ES实例堆的大小可以设到64GB

检查堆内存设置到多大，是否能够开启指针压缩技术

java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops

如上，表示如果最大堆内存设为32766MB，jvm是否会开启指针压缩

详见参考资料[2]

6. 参与选主的机器，不要设定的过多

1）在ES中，只有能够参与选主的ES实例（master-eligible node），才能被选为Master节点，某个实例必须收到超过半数投票人的投票，才能当选为master节点
经验表明，参与选主的机器过多，集群会变得非常不稳定
正如人类社会的代议制一样，如果每一个决策都需要全体国民决定，那这个决策过程，会变得非常低效。
2）另外 参与选主的ES实例不要存放数据，也不作为client

By default a node is a master-eligible node and a data node, plus it can pre-process documents through ingest pipelines. This is very convenient for small clusters but, as the cluster grows, it becomes important to consider separating dedicated master-eligible nodes from dedicated data nodes.

从实践经验看，在集群中，挑选3个实例参与选主即可，堆内存可设为16GB。可以与其他ES实例混部。
见参考资料[3]

7. HugePage引发的问题

在我们的集群运行在centos6上，有段时间，我们密集的导入一批数据，观察部分节点的负载在集群中显得十分突兀，影响了整体的吞能力，结果发现是centos默认开启了HugePage，导致cpu_sys 过高
可用以下命令关闭THP特性

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag

注意 ： 该配置重启后会失效