转载 http://www.cnblogs.com/hseagle/p/6015245.html 该es调优版本可能有低,但是思想主体不变,不合适的参数可以自己找最新的版本相应的替代,或者增删 elasticsearch性能调优 集群规划 独立的master节点,不存储数据, 数量不少于2 数据节点(Data Node) 查询节点(Query Node),起到负载均衡的作用 Linux系统参数配置 文件句柄 Linux中,每个进程默认打开的最大文件句柄数是1000,对于服务器进程来说,显然太小,

How To Elasticsearch默认是提供了一个非常简单的即开即用体验.用户无需修改什么配置就可以直接使用全文检索.结果高亮.聚合.索引功能. 但是想在项目中使用高性能的Elasticsearch,有几方面优化方法最好掌握. 本文就是为了引导如何优化. 常规建议 不要一次返回太大量的搜索结果集 Elasticsearch设计作为一个搜索引擎,非常擅长返回匹配的查询结果.但是,它并不合适像数据库一样,把整个document作为查询结果返回.如果非要这样做,最好还是使用Scroll这个接口来

来源:http://tinyurl.com/y4gnzbje 第一部分:调优索引速度 第二部分-调优搜索速度 第三部分:通用的一些建议 英文原文:https://www.elastic.co/guide/en/elasticsearch/reference/current/how-to.html ES发布时带有的默认值,可为es的开箱即用带来很好的体验.全文搜索.高亮.聚合.索引文档 等功能无需用户修改即可使用,当你更清楚的知道你想如何使用es后,你可以作很多的优化以提高你的用例的性能,下面的内

来源:http://tinyurl.com/y4gnzbje 第一部分:调优索引速度 第二部分-调优搜索速度 英文原文:https://www.elastic.co/guide/en/elasticsearch/reference/current/how-to.html ES发布时带有的默认值,可为es的开箱即用带来很好的体验.全文搜索.高亮.聚合.索引文档 等功能无需用户修改即可使用,当你更清楚的知道你想如何使用es后,你可以作很多的优化以提高你的用例的性能,下面的内容告诉你 你应该/不应该

ES 发布时带有的默认值,可为 ES 的开箱即用带来很好的体验.全文搜索.高亮.聚合.索引文档 等功能无需用户修改即可使用,当你更清楚的知道你想如何使用 ES 后,你可以作很多的优化以提高你的用例的性能,下面的内容告诉你 你应该/不应该 修改哪些配置. 第一部分:调优索引速度 使用批量请求批量请求将产生比单文档索引请求好得多的性能. 为了知道批量请求的最佳大小,您应该在具有单个分片的单个节点上运行基准测试. 首先尝试索引100个文件,然后是200,然后是400,等等. 当索引速度开始稳定时,您知

1. 近期遇到一个ES内存居高不下的问题,查了查,发现ES有个fielddata,当你发起一个查询,分析字符串的聚合将会被加载到 fielddata,如果这些字符串之前没有被加载过.如果结果中 fielddata 大小超过了指定 大小 ,其他的值将会被回收从而获得空间.默认情况下,设置都是 unbounded ,Elasticsearch 永远都不会从 fielddata 中回收数据.设想我们正在对日志进行索引,每天使用一个新的索引.通常我们只对过去一两天的数据感兴趣,尽管我们会保留老的索引,但

  基于版本: 2.x – 5.x 在 es 的默认设置,是综合考虑数据可靠性,搜索实时性,写入速度等因素的,当你离开默认设置,追求极致的写入速度时,很多是以牺牲可靠性和搜索实时性为代价的.有时候,业务上对两者要求并不高,反而对写入速度要求很高,例如在我的场景中,要求每秒200w 条的平均写入速度,每条500字节左右 接下来的优化基于集群正常运行的前提下,如果是集群首次灌入数据,可以将副本数设置为0,写入完毕再调整回去,这样副本分片只需要拷贝,节省了索引过程. 综合来说,提升写入速度从以下几方面

对于索引分片数量,我们一般在模板中统一定义,在数据规模比较大的集群中,索引分片数一般也大一些,在我的集群中设置为 24.但是,并不是所有的索引数据量都很大,这些小数据量的索引也同样有较大的分片数.在 elasticsearch 中,主节点管理分片是很大的工作量,降低集群整体分片数量可以降低 recovery 时间,减小集群状态的大小.很多时候,冷索引不会再有数据写入,此时,可以使用 shrink API 缩小索引分配数.缩小完成后,源索引可删除. shrink API 是 es5.0之后提供的新

前言 elasticsearch提供了非常灵活的搜索条件给我们使用,在使用复杂表达式的同时,如果使用不当,可能也会为我们带来了潜在的风险,因为影响查询性能的因素很多很多,这篇笔记主要记录一下慢查询可能的原因,及其优化的方向. 本文讨论的es版本为7.0+. 慢查询现象 查询服务超时 最直观的现象就是提供查询的服务响应超时. 大量连接被拒绝 我们有时候写查询,为了图方遍,经常使用通配符*来查询,这有可能会匹配到多个索引,由于索引下分片太多,超过了集群中的核心数.就会在搜索线程池中造成排队任务,从而

本章讨论搜索速度优化:搜索速度与系统资源.数据索引方式.查询方式等多方面 1.为文件系统cache预留足够的内存 1)应用程序一般情况下,读写都会被操作系统“cache” 2)cache保存在物理内存中,命中cache可以降低对磁盘的读写频率 3)搜索对系统cache很依赖,如果搜索从磁盘读取数据,则一定会产生相对较高的延迟 4)应该至少为系统cache预留一般的可用内存,更大内存可以有更高的cache命中率 5)线上应禁用swap 2.使用更快的硬件 1)写入对CPU更敏感.而搜索对IO能力需

elasticsearch性能调优 集群规划 独立的master节点,不存储数据, 数量不少于2 数据节点(Data Node) 查询节点(Query Node),起到负载均衡的作用 Linux系统参数配置 文件句柄 Linux中,每个进程默认打开的最大文件句柄数是1000,对于服务器进程来说,显然太小,通过修改/etc/security/limits.conf来增大打开最大句柄数 * - nofile 65535 虚拟内存设置 max_map_count定义了进程能拥有的最多内存区域 sysc

ElasticSearch是现在技术前沿的大数据引擎,常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统,其中Logstash是ETL工具,Kibana是数据分析展示平台.ES让人惊艳的是他强大的搜索相关能力和灾备策略,ES开放了一些接口供开发者研发自己的插件,ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用.ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的,说架构必须和Lucene的一些东西打交道. 关于Lucene: Ap

所有的修改都可以在elasticsearch.yml里面修改,也可以通过api来修改.推荐用api比较灵活 1.不同分片之间的数据同步是一个很大的花费,默认是1s同步,如果我们不要求实时性,我们可以执行如下: $ curl -XPUT 'http://localhost:9200/twitter/' -d '{ "settings" : { "index" : { "refresh_interval":"60s" } } }'

系统调优 禁用swap 使用swapoff命令可以暂时关闭swap.永久关闭需要编辑/etc/fstab,注释掉swap设备的挂载项. swapoff -a 如果完全关闭swap不可行,可以试着降低swap使用的优先级,执行 sysctl vm.swappiness = 1 并编辑/etc/sysctl.conf,加入swappiness设置. 如果因为一些原因,无法对swap进行操作,可以将ES配置中的memory_lock设置为true,从JVM层面保证内存数据交换到swap中. boots

Index Settings 重要索引配置 Index level settings can be set per-index. Settings may be: 1 static 静态索引配置 They can only be set at index creation time or on a closed index. 只能在创建索引时设置或者在closed状态的索引上设置: index.number_of_shards The number of primary shards that

[root@es-node1 ~]# mkdir /usr/java[root@es-node1 ~]# tar zxvf jdk1.8.0_131.tar.gz -C /usr/java/ [root@es-node1 ~]# cp /etc/profile /etc/profile.back[root@es-node1 ~]# vim /etc/profileexport JAVA_HOME=/usr/java/jdk1.8.0_131/export CLASSPATH=$CLASSPATH

ElasticSearch 2 (12) - Shard数调优(ElasticSearch性能) 摘要 当创建一个索引的时候,我们经常会面对一个问题:要为索引分配多少个shard?多少个replica?对于这个问题,仍然没有明确的统一答案,但是本文会给出一些引导,方便在实施ElasticSearch时给出合适的Shard和Replica数. 版本 elasticsearch版本: elasticsearch-2.x 内容 什么是一个Shard? Shard就是一个Lucene Index,参照文

ElasticSearch 2 (11) - 节点调优(ElasticSearch性能) 摘要 一个ElasticSearch集群需要多少个节点很难用一种明确的方式回答,但是,我们可以将问题细化成一下几个,以便帮助我们更好的了解,如何去设计ElasticSearch节点的数目: 打算处理多少数据? 打算处理多少搜索请求? 请求的复杂度是怎样? 每个节点有多少资源数? 打算建立多少索引,支持多少应用? 版本 elasticsearch版本: elasticsearch-2.x 内容 一个集群解决所

一.简介 ElasticSearch是一个基于Lucene的搜索服务器.它提供了一个分布式多用户能力的全文搜索引擎,基于RESTful web接口.Elasticsearch是用Java开发的,并作为Apache许可条款下的开放源码发布,是当前流行的企业级搜索引擎. 它不但包括了全文搜索功能,还可以进行以下工作: 分布式实时文件存储,并将每一个字段都编入索引,使其可以被搜索. 实时分析的分布式搜索引擎. 可以扩展到上百台服务器,处理PB级别的结构化或非结构化数据. 使用案例: 维基百科使用Ela

lasticSearch是现在技术前沿的大数据引擎,常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统,其中Logstash是ETL工具,Kibana是数据分析展示平台.ES让人惊艳的是他强大的搜索相关能力和灾备策略,ES开放了一些接口供开发者研发自己的插件,ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用.ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的,说架构必须和Lucene的一些东西打交道.关于Lucene: Apac