Elasticsearch之优化

 为什么es需要优化？

　　答：

怎么来做好es的优化工作？

1、解决es启动的警告信息【或者es中Too many open files的问题】

　　max file descriptors [4096] for elasticsearch process likely too low, consider increasing to at least [65536]

　　vi /etc/security/limits.conf 添加下面两行

　　* soft nofile 65536

　　* hard nofile 131072

2、修改配置文件调整ES的JVM内存大小

　　修改bin/elasticsearch.in.sh中ES_MIN_MEM和ES_MAX_MEM的大小，建议设置一样大，避免频繁的分配内存，根据服务器内存大小，一般分配60%左右(默认256M)

　　注意：内存最大不要超过32G【详情请看备注】

　　一旦你越过这个神奇的32 GB边界，指针会切换回普通对象指针.。每个指针的大小增加，使用更多的CPU内存带宽。事实上，你使用40~50G的内存和使用32G的内存效果是一样的。

3、设置memory_lock来锁定进程的物理内存地址

　　避免交换（swapped）来提高性能

　　修改文件conf/elasticsearch.yml

　　bootstrap.memory_lock: true

分片多的话，可以提升建立索引的能力，5-20个比较合适。

　　如果分片数过少或过多，都会导致检索比较慢。

　　分片数过多会导致检索时打开比较多的文件，另外也会导致多台服务器之间通讯。

　　而分片数过少会导至单个分片索引过大，所以检索速度也会慢。

　　建议单个分片最多存储20G左右的索引数据，所以，分片数量=数据总量/20G

副本多的话，可以提升搜索的能力，但是如果设置很多副本的话也会对服务器造成额外的压力，因为需要主分片需要给所有副本同步数据。所以建议最多设置1-2个即可。

Elastic 官方文档建议：一个 es实例中 最好不要多于三个 shards，若是 "more shards”，只能增加更多的机器 ，如果服务器性能好的话可以在一台服务器上启动多个es实例

要定时对索引进行合并优化，不然segment越多，占用的segment memory越多，查询的性能也越差

　　索引量不是很大的话情况下可以将segment设置为1

　　在es2.1.0以前调用_optimize接口，后期改为_forcemerge接口

　　curl -XPOST ‘http://localhost:9200/zhouls/_forcemerge?max_num_segments=1‘

　　client.admin().indices().prepareForceMerge("yehua").setMaxNumSegments(1).get();

针对不使用的index，建议close，减少内存占用。因为只要索引处于open状态，索引库中的segement就会占用内存，close之后就只会占用磁盘空间了。

curl -XPOST ‘localhost:9200/zhouls/_close‘

删除文档：在es中删除文档，数据不会马上在硬盘上除去，而是在es索引中产生一个.del的文件，而在检索过程中这部分数据也会参与检索，es在检索过程会判断是否删除了，如果删除了在过滤掉。这样也会降低检索效率。所以可以执行清除删除文档

curl -XPOST ‘http://192.168.80.10:9200/zhouls/_forcemerge?only_expunge_deletes=true‘

client.admin().indices().prepareForceMerge("zhouls").setOnlyExpungeDeletes(true).get();

如果在项目开始的时候需要批量入库大量数据的话，建议将副本数设置为0

　　因为es在索引数据的时候，如果有副本存在，数据也会马上同步到副本中，这样会对es增加压力。可以等索引完成后将副本按需要改回来。这样可以提高索引效率

去掉mapping中_all字段，Index中默认会有_all这个字段，默认会把所有字段的内容都拷贝到这一个字段里面，这样会给查询带来方便，但是会增加索引时间和索引尺寸

　　禁用_all字段  "_all":{"enabled":false}

　　如果只是某个字段不希望被加到_all中，可以使用 "include_in_all":false

log输出的水平默认为trace，即查询超过500ms即为慢查询，就要打印日志，造成cpu和mem，io负载很高。把log输出水平改为info，可以减轻服务器的压力。

修改ES_HOME/conf/logging.yaml文件

途径1:可以解决es的警告信息

　　 其实啊，若我们在ES_HOME目录下，不用后台bin/elasticsearch -d这种方式来启动的话，用前台bin/elasticsearch。则会看到，如下：

　　说明，我这里是因为安装了tomcat。所以，在前台直接启动，会出错。

　  所以，

[[email protected] bin]$ pwd
/home/hadoop/app/tomcat-7.0.73/bin
[[email protected] bin]$ ./startup.sh
Using CATALINA_BASE: /home/hadoop/app/tomcat-7.0.73
Using CATALINA_HOME: /home/hadoop/app/tomcat-7.0.73
Using CATALINA_TMPDIR: /home/hadoop/app/tomcat-7.0.73/temp
Using JRE_HOME: /home/hadoop/app/jdk1.7.0_79/jre
Using CLASSPATH: /home/hadoop/app/tomcat-7.0.73/bin/bootstrap.jar:/home/hadoop/app/tomcat-7.0.73/bin/tomcat-juli.jar
Tomcat started.
[[email protected] bin]$ jps
2916 Jps
2906 Bootstrap
[[email protected] bin]$ cd ..
[[email protected] tomcat-7.0.73]$ cd ..
[[email protected] app]$ cd elasticsearch-2.4.3/
[[email protected] elasticsearch-2.4.3]$ bin/elasticsearch
[2017-02-28 22:08:49,862][WARN ][bootstrap ] unable to install syscall filter: seccomp unavailable: requires kernel 3.5+ with CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER compiled in
[2017-02-28 22:08:51,324][INFO ][node ] [Dragonwing] version[2.4.3], pid[2930], build[d38a34e/2016-12-07T16:28:56Z]
[2017-02-28 22:08:51,324][INFO ][node ] [Dragonwing] initializing ...
[2017-02-28 22:08:55,760][INFO ][plugins ] [Dragonwing] modules [lang-groovy, reindex, lang-expression], plugins [analysis-ik, kopf, head], sites [kopf, head]
[2017-02-28 22:08:55,846][INFO ][env ] [Dragonwing] using [1] data paths, mounts [[/home (/dev/sda5)]], net usable_space [23.4gb], net total_space [26.1gb], spins? [possibly], types [ext4]
[2017-02-28 22:08:55,846][INFO ][env ] [Dragonwing] heap size [1015.6mb], compressed ordinary object pointers [true]
[2017-02-28 22:08:55,848][WARN ][env ] [Dragonwing] max file descriptors [4096] for elasticsearch process likely too low, consider increasing to at least [65536]
[2017-02-28 22:09:00,957][INFO ][ik-analyzer ] try load config from /home/hadoop/app/elasticsearch-2.4.3/config/analysis-ik/IKAnalyzer.cfg.xml
[2017-02-28 22:09:00,959][INFO ][ik-analyzer ] try load config from /home/hadoop/app/elasticsearch-2.4.3/plugins/ik/config/IKAnalyzer.cfg.xml
[2017-02-28 22:09:01,925][INFO ][ik-analyzer ] [Dict Loading] custom/mydict.dic
[2017-02-28 22:09:01,926][INFO ][ik-analyzer ] [Dict Loading] custom/single_word_low_freq.dic
[2017-02-28 22:09:01,932][INFO ][ik-analyzer ] [Dict Loading] custom/zhouls.dic
[2017-02-28 22:09:01,933][INFO ][ik-analyzer ] [Dict Loading] http://192.168.80.10:8081/zhoulshot.dic
[2017-02-28 22:09:09,451][INFO ][ik-analyzer ] 好记性不如烂笔头感叹号博客园热更新词
[2017-02-28 22:09:09,550][INFO ][ik-analyzer ] 桂林不雾霾
[2017-02-28 22:09:09,615][INFO ][ik-analyzer ] [Dict Loading] custom/ext_stopword.dic
[2017-02-28 22:09:13,620][INFO ][node ] [Dragonwing] initialized
[2017-02-28 22:09:13,621][INFO ][node ] [Dragonwing] starting ...
[2017-02-28 22:09:13,932][INFO ][transport ] [Dragonwing] publish_address {192.168.80.10:9300}, bound_addresses {[::]:9300}
[2017-02-28 22:09:13,960][INFO ][discovery ] [Dragonwing] elasticsearch/eKzsH0g5QoGl6pQlCG4mOQ
[2017-02-28 22:09:17,357][INFO ][cluster.service ] [Dragonwing] detected_master {Carrie Alexander}{98-Mux6mQsu1oE__EJN7yQ}{192.168.80.11}{192.168.80.11:9300}, added {{Carrie Alexander}{98-Mux6mQsu1oE__EJN7yQ}{192.168.80.11}{192.168.80.11:9300},{Shocker}{u_IYMF3ISe6_iki9KwxPCA}{192.168.80.12}{192.168.80.12:9300},}, reason: zen-disco-receive(from master [{Carrie Alexander}{98-Mux6mQsu1oE__EJN7yQ}{192.168.80.11}{192.168.80.11:9300}])
[2017-02-28 22:09:17,637][INFO ][http ] [Dragonwing] publish_address {192.168.80.10:9200}, bound_addresses {[::]:9200}
[2017-02-28 22:09:17,638][INFO ][node ] [Dragonwing] started
[2017-02-28 22:09:19,812][INFO ][ik-analyzer ] 重新加载词典...
[2017-02-28 22:09:19,816][INFO ][ik-analyzer ] try load config from /home/hadoop/app/elasticsearch-2.4.3/config/analysis-ik/IKAnalyzer.cfg.xml
[2017-02-28 22:09:19,820][INFO ][ik-analyzer ] try load config from /home/hadoop/app/elasticsearch-2.4.3/plugins/ik/config/IKAnalyzer.cfg.xml
[2017-02-28 22:09:23,102][WARN ][monitor.jvm ] [Dragonwing] [gc][young][8][7] duration [1.6s], collections [1]/[1.9s], total [1.6s]/[5.2s], memory [121.7mb]->[79.4mb]/[1015.6mb], all_pools {[young] [59.9mb]->[457kb]/[66.5mb]}{[survivor] [8.2mb]->[8.3mb]/[8.3mb]}{[old] [53.5mb]->[70.6mb]/[940.8mb]}
[2017-02-28 22:09:23,946][INFO ][ik-analyzer ] [Dict Loading] custom/mydict.dic
[2017-02-28 22:09:23,947][INFO ][ik-analyzer ] [Dict Loading] custom/single_word_low_freq.dic
[2017-02-28 22:09:23,953][INFO ][ik-analyzer ] [Dict Loading] custom/zhouls.dic
[2017-02-28 22:09:23,955][INFO ][ik-analyzer ] [Dict Loading] http://192.168.80.10:8081/zhoulshot.dic
[2017-02-28 22:09:23,996][INFO ][ik-analyzer ] 好记性不如烂笔头感叹号博客园热更新词
[2017-02-28 22:09:23,997][INFO ][ik-analyzer ] 桂林不雾霾
[2017-02-28 22:09:24,000][INFO ][ik-analyzer ] [Dict Loading] custom/ext_stopword.dic
[2017-02-28 22:09:24,002][INFO ][ik-analyzer ] 重新加载词典完毕...

　　

　　更详细，es的前台和后台启动，请移步

Elasticsearch之启动（前台和后台）

　　怎么做，如下：

时间： 2024-08-25 20:18:02

Elasticsearch之优化的相关文章

ElasticSearch性能优化方案

ElasticSearch性能优化主要分为4个方面的优化. 一.服务器部署 1.增加1-2台服务器,用于负载均衡节点elasticSearch的配置文件中有2个参数:node.master和node.data.这两个参数搭配使用时,能够帮助提供服务器性能. node.master: false node.data: true 该node服务器只作为一个数据节点,只用于存储索引数据.使该node服务器功能 单一,只用于数据存储和数据查询,降低其资源消耗率. node.master: true no

亿级 Elasticsearch 性能优化

前言 最近一年使用 Elasticsearch 完成亿级别日志搜索平台「ELK」,亿级别的分布式跟踪系统.在设计这些系统的过程中,底层都是采用 Elasticsearch 来做数据的存储,并且数据量都超过亿级别,甚至达到百亿级别. 所以趁着有空,就花点时间整理一下具体怎么做 Elasticsearch 性能优化,希望能对 Elasticsearch 感兴趣的同学有所帮助. 背景 Elasticsearch 是一个基于 Lucene 的搜索服务器.它提供了一个分布式多用户能力的全文搜索引擎,基于

elasticsearch 性能优化

#系统默认的最大打开文件数的限制 vi /etc/security/limits.conf *     -       nproc          50240 *     -       nofile          20480 #65535 *                -       npro            20480 *                -       nofile          65535 *                -       memlock

分布式搜索引擎Elasticsearch性能优化与配置

1.内存优化 在bin/elasticsearch.in.sh中进行配置 修改配置项为尽量大的内存: ES_MIN_MEM=8g ES_MAX_MEM=8g 两者最好改成一样的,否则容易引发长时间GC(stop-the-world) elasticsearch默认使用的GC是CMS GC,如果你的内存大小超过6G,CMS是不给力的,容易出现stop-the-world,建议使用G1 GC JAVA_OPTS=”$JAVA_OPTS -XX:+UseParNewGC” JAVA_OPTS=”$JA

elasticsearch配置优化

http://m.blog.csdn.net/article/details?id=50330149 节点 Elasticsearch 节点有四种 : master and data--- 默认是这种配置,既存储数据,也可以成为master节点 only master --- 协调各个节点间均衡,如分片的移动 only data --- 只存储数据,此种节点的http.enable: false 可设置成false No data and no master --- 既不是master,也不存储

Mac安装6.1.2版本Elasticsearch及优化配置实践

1,Mac上安装(指定java8) brew cask install java8 vim .base_profile 文件内容: JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home PATH=$JAVA_HOME/bin:$PATH CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar source .base_profile ech

ElasticSearch性能优化

一.搜索效率优化 批量提交 当有大量数据提交的时候,建议采用批量提交. 比如在做 ELK 过程中 ,Logstash indexer 提交数据到 Elasticsearch 中 ,batch size 就可以作为一个优化功能点.但是优化 size 大小需要根据文档大小和服务器性能而定. 像 Logstash 中提交文档大小超过 20MB ,Logstash 会请一个批量请求切分为多个批量请求. 如果在提交过程中,遇到 EsRejectedExecutionException 异常的话,则说明集群

Elasticsearch聚合优化 | 聚合速度提升5倍

https://blog.csdn.net/laoyang360/article/details/79253294 1.聚合为什么慢?大多数时候对单个字段的聚合查询还是非常快的, 但是当需要同时聚合多个字段时,就可能会产生大量的分组,最终结果就是占用 es 大量内存,从而导致 OOM 的情况发生. 实践应用发现,以下情况都会比较慢: 1)待聚合文档数比较多(千万.亿.十亿甚至更多): 2)聚合条件比较复杂(多重条件聚合): 3)全量聚合(翻页的场景用). 2.聚合优化方案探讨优化方案一:默认深度

Elasticsearch性能优化实战指南

作者:铭毅天下 背景在当今世界,各行各业每天都有海量数据产生,为了从这些海量数据中获取想要的分析结果,需要对数据进行提取.转换,存储,维护,管理和分析. 这已然远远超出了普通处理工具.数据库等的实现能力,只有基于的分布式架构和并行处理机制的大数据工具所才能实现这些功能.Elasticsearch是响应如前所述大多数用例的最热门的开源数据存储引擎之一.Elasticsearch是一种分布式数据存储和搜索引擎,具有容错和高可用性特点.为了充分利用其搜索功能,需要正确配置Elasticsearch.简