Elasticsearch性能因素总结
Elasticsearch性能优化可以分为四个模块来进行，分别是硬件、操作系统、Elasticsearch参数配置以及查询优化。
硬件优化
在预算充足的情况下。特别是一些高并发业务的搜索。硬件层面占用整个elasticsearch性能空间很大比例。
- 内存
根据业务量不同，内存的需求也不同，一般生产建议不要少于16G。ES是比较依赖内存的，并且对内存的消耗也很大，内存对ES的重要性甚至是高于CPU的，所以即使是数据量不大的业务，为了保证服务的稳定性，在满足业务需求的前提下，我们仍需考虑留有不少于20%的冗余性能。一般来说，按照百万级、千万级、亿级数据的索引，我们为每个节点分配的内存为16G/32G/64G就足够了。 - 硬盘
对于ES来说，硬盘可能是最重要的了，因为数据都是存储在磁盘上的，当然这里说的磁盘指的是磁盘的性能。磁盘性能往往是硬件性能的瓶颈，木桶效应中的最短板。ES应用可能要面临不间断的大量的数据读取和写入。建议使用一些高性能io的硬盘，SSD。 - CPU
在高并发的情况下，cpu的计算能力要求就很高了。cpu配置尽量高。 - 网络
ES是自带分布式属性的，并且ES的分布式系统是基于对等网络的，节点与节点之间的通信十分的频繁，延迟对于ES的用户体验是致命的，所以对于ES来说，低延迟的网络是非常有必要的。
操作系统优化
- 设置最大文件打开数
ulimit -a 查看
ulimit -HSn 655360 s 代表软件资源，n代表硬件资源 系统重启之后恢复默认
echo "* soft nofile 655360
* hard nofile 655360
* soft nproc 77823
* hard nproc 77823
* hard memlock unlimited
* soft memlock unlimited" >> /etc/security/limits.conf- 优化相关内核及内存参数
sysctl -w vm.swappiness=1
sysctl -w vm.overcommit_memory=1
sysctl -w net.core.somaxconn=2048
sysctl -w vm.max_map_count=262144
echo "vm.overcommit_memory=1" >> /etc/sysctl.conf
echo "vm.swappiness=1" >> /etc/sysctl.conf
echo "net.core.somaxconn=2048" >> /etc/sysctl.conf
echo "vm.max_map_count=262144" >> /etc/sysctl.conf
sysctl -p
swappiness：取值0-100，越低，不积极依赖交换空间、越高，积极依赖交换空间
overcommit_memory：是一个内核对内存分配的一种策略。取值又三种分别为0（表示内核将检查是否有足够的可用内存供应用进程使用；如果有足够的可用内存，内存申请允许；否则，内存申请失败，并把错误返回给应用进程），1（表示内核允许分配所有的物理内存，而不管当前的内存状态如何），2（表示内核允许分配超过所有物理内存和交换空间总和的内存）。
max_map_count：是一个与内核虚拟内存子系统相关的参数，用于控制进程可以拥有的内存映射区域的最大数量。它通常用于限制一个进程可以打开的文件数量，特别是在使用大量内存映射文件的情况下。
net.core.somaxconn：是TCP/IP协议栈内核参数之一，用于指定处于监听状态的连接请求队列的最大长度- 关闭transparent_hugepage
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
echo "############################################
#disable THP
############################################
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi" >> /etc/rc.d/rc.localElasticsearch参数优化
- 优化GC，减少GC时间
修改config/jvm.options文件中-Xms、-Xmx，建议设置为操作系统内存的一半，一般生产建议不要少于16G。 - 调整ping机制
如果有节点超时，master默认ping3次（zen discovery默认ping失败重试3次）不通后就会把该节点剔除出集群，从而导致索引进行重新分配。
discovery.zen.fd.ping_timeout: 60s ###超时时间
discovery.zen.fd.ping_retries: 6 ###ping重试次数
discovery.zen.fd.ping_interval: 10s ###ping间隔时间- 分片优化
按自己的业务需求控制shard数量，shard过多，交互多。shard过少，单个分片数据容易累积，当单个分片的数据超过30G的时候就有性能下降的情况，当超过50G的时候，就有明显性能下降的效果。
集群分片规范：
- 控制每个分片大小不超过30G，不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32 G），因此，如果索引的总容量在 500 G 左右，那分片大小在 16 个左右即可。
- 考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，导致数据分布不均匀，部分节点磁盘使用率高。所以，建议单个索引分片数量不超过节点数量。- 锁住ES内存
ES在内存不够JVM开启swapping的时候，表现得会很差，所以为了避免这个问题，将该属性设为true，表示锁定es所使用的内存:
bootstrap.memory_lock: true查询优化
- 避免单次召回大量数据
搜索引擎最擅长的事情是从海量数据中查询少量相关文档，而非单次检索大量文档。非常不建议动辄查询上万数据。如果有这样的需求，建议使用滚动查询。 - 避免单个文档过大
鉴于默认http.max_content_length设置为 100MB，Elasticsearch 将拒绝索引任何大于该值的文档。您可能决定增加该特定设置，但 Lucene 仍然有大约 2GB 的限制。即使不考虑硬性限制，大型文档通常也不实用。大型文档对网络、内存使用和磁盘造成了更大的压力，即使对于不请求的搜索请求也是如此，_source因为 Elasticsearch_id在所有情况下都需要获取文档的文件系统缓存有效。对该文档进行索引可能会占用文档原始大小的倍数的内存量。 - 单次查询10条文档，好于10次查询每次一条
批量请求将产生比单文档索引请求更好的性能。但是每次查询多少文档最佳，不同的集群最佳值可能不同，为了获得批量请求的最佳阈值，建议在具有单个分片的单个节点上运行基准测试。 - 使用filter代替query
query和filter的主要区别在： filter是结果导向的而query是过程导向。query倾向于“当前文档和查询的语句的相关度”而filter倾向于“当前文档和查询的条件是不是相符”。即在查询过程中，query是要对查询的每个结果计算相关性得分的，而filter不会。另外filter有相应的缓存机制，可以提高查询效率。 - 避免深度分页
避免单页数据过大。es提供两种解决方案 scroll search 和 search after。 - 使用Keyword类型
并非所有数值数据都应映射为数值字段数据类型。Elasticsearch为 查询优化数字字段，例如integeror long。如果不需要范围查找，对于 term查询而言，keyword 比 integer 性能更好。