ElasticSearch优化系列七：优化建议

Posted 2023-04-21

参考技术A

a) JVM内存设置不要超过机器的一半内存，并且不超过32G。（./bin/elasticsearch -Xmx10g -Xms10g或者修改./bin/elasticsearch.in.sh文件：

** 一般分配主机1/4-1/2的内存**

设置每个线程的堆栈大小, ES单线程承载的数据量比较大
JAVA_OPTS="$JAVA_OPTS -Xss128m"

b) 修改swapping参数，内存不够用时才进行swapping（vm.swappiness= 1）
c) 暂时不要修改GC方法
d）锁定内存，不让JVM写入swapping，避免降低ES的 性能
bootstrap.mlockall: true
e）缓存类型设置为Soft Reference，只有当内存不够时才会进行回收
index.cache.field.max_size: 50000 index.cache.field.expire: 10m index.cache.field.type: soft

4.权衡建索引的性能和检索的时效性，修改以下参数。

5.倒排词典的索引需要常驻内存，无法GC，需要监控data node上segment
memory增长趋势。

定期对不再更新的索引做optimize (ES2.0以后更改为force merge api)。这Optimze的实质是对segment file强制做合并，可以节省大量的segment memory

6.根据机器数，磁盘数，索引大小等硬件环境，根据测试结果，设置最优的分片数和备份数，单个分片最好不超过10GB，定期删除不用的索引，做好冷数据的迁移。

7.保守配置内存限制参数，尽量使用doc value存储以减少内存消耗，查询时限制size、from参数。

8.如果不使用_all字段最好关闭这个属性，否则在创建索引和增大索引大小的时候会使用额外更多的CPU，如果你不受限CPU计算能力可以选择压缩文档的_source。这实际上就是整行日志，所以开启压缩可以减小索引大小。

9.避免返回大量结果集的搜索与聚合。缺失需要大量拉取数据可以采用scan & scroll api来实现。

10.熟悉各类缓存作用，如field cache, filter cache, indexing cache, bulk queue等等，要设置合理的大小，并且要应该根据最坏的情况来看heap是否够用。

11.必须结合实际应用场景，并对集群使用情况做持续的监控。

ElasticSearch实战-索引优化建议与原则

        在设计 Elasticsearch 索引之前，首先要合理地估算自己的物理需求，物理需求指数据本身的物理特性，包括如下几方面。     

• 数据总量

        业务所涉及的领域对象预期有多少条记录，对 Elasticsearch 来说就是有多少 documents 需要索引到集群中。

• 单条数据大小

        每条数据的各个属性的物理大小是多少，比如 1k 还是 10k。

• 长文本

        明确数据集中是否有长文本，明确长文本是否需要检索，是否可以启用压缩。Elasticsearch 建索引的过程是极其消耗 CPU 的，尤其对长文本更是如此。

        明确了长文本的用途并合理地进行相关设置可以提高 CPU、磁盘、内存利用率。我们曾遇见过不合理的长文本处理方式导致的问题，此处在 mapping 设计时会专门讨论。

• 物理总大小

        根据上面估算的数据总量和单条数据大小，就可以估算出预期的存储空间大小。

• 数据增量方式

        这里主要明确数据是以何种方式纳入 Elasticsearch 的管理，比如平稳增加、定期全量索引、周期性批量导入。针对不同的数据增量方式，结合 Elasticsearch 提供的灵活设置，可以最大化地提高系统的性能。

• 数据生命周期

        数据生命周期指进入到系统的数据保留周期，是永久保留、还是随着时间推移进行老化处理？老化的周期是多久？既