在 Mapping 里面,将 dynamic 参数设置成 strict 可以拒绝索引包含未知字段的文档。 此条 Tips 由 medcl 贡献。

Day1: 大规模Elasticsearch集群管理心得

Advent | 作者 kennywu76 | 发布于2016年12月02日 | | 阅读数:47873

【携程旅行网 吴晓刚】
 ElasticSearch目前在互联网公司主要用于两种应用场景,其一是用于构建业务的搜索功能模块且多是垂直领域的搜索,数据量级一般在千万至数十亿这个级别;其二用于大规模数据的实时OLAP,经典的如ELKStack,数据规模可能达到千亿或更多。 这两种场景的数据索引和应用访问模式上差异较大,在硬件选型和集群优化方面侧重点也会有所不同。一般来说后一种场景属于大数据范畴,数据量级和集群规模更大,在管理方面也更有挑战。

应Medcl大大的邀请,为ES中文社区做今年的Advent开篇,分享一下我在管理自家公司用于日志分析的ES集群方面的一点心得,蜻蜓点水,泛泛而谈,希望大方向上能对大家提供一些帮助。

这里的自家,即是携程旅行网。从2013年开始接触ES,我们团队先后实践过0.9.x -> 5.0.0中间各个版本,从最初只用于运维内部IIS日志的分析,到如今支持IT、呼叫中心、安全、测试、业务研发等多个部门超过200种日志型数据的实时检索与分析。 一路走来,愉悦了大家,也死磕了自己。

目前我们最大的日志单集群有120个data node,运行于70台物理服务器上。数据规模如下:
  • 单日索引数据条数600亿,新增索引文件25TB (含一个复制片则为50TB)
  • 业务高峰期峰值索引速率维持在百万条/秒
  • 历史数据保留时长根据业务需求制定,从10天 - 90天不等
  • 集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB
  • Kibana用户600多人, 每日来自Kibana和第三方的API调用共63万次
  • 查询响应时间百分位 75%:0.160s  90%:1.640s 95%:6.691s 99%:14.0039s


运维这样大规模的ES集群,有哪些值得注意的地方?

一. 必不可少的工具
工欲善其事必先利其器,从一开始,哪怕就只有几个node,就应该使用分布式配置管理工具来做集群的部署。随着应用的成熟,集群规模的逐步扩大,效率的提升会凸显。 官方提供了ES Puppet Module和Chef Cookbook,熟悉这两个工具的同学可以直接拿过来用。 我们自己则是采用的Ansible,编写了一套Playbook来达到类似的效果。 用熟这类工具,对于集群的初始部署,配置批量更改,集群版本升级,重启故障结点都会快捷和安全许多。
第二个必备利器就是sense插件。通过这个插件直接调用集群的restful API,在做集群和索引的状态查看,索引配置更改的时候非常方便。语法提示和自动补全功能更是实用,减少了翻看文档的频率。在Kibana5里面,sense已经成为一个内置的控制台,无需额外安装。

二. 硬件配置
我们采用的是32vcoreCPU + 128GB RAM的服务器,磁盘配置大部分服务器是12块4TB SATA机械磁盘做的Raid0,少部分机器是刚上了不久的6块800GB SSD raid0,主要目的是想做冷热数据分离,后面谈到集群架构的时候,再进一步解释一下如何利用硬件资源。

三. 集群的管理
  1. 首先很有必要对ES的结点做角色划分和隔离。大家知道ES的data node除了放数据以外,也可以兼任master和client的角色,多数同学会将这些角色混入到data node。然而对于一个规模较大,用户较多的集群,master和client在一些极端使用情况下可能会有性能瓶颈甚至内存溢出,从而使得共存的data node故障。data node的故障恢复涉及到数据的迁移,对集群资源有一定消耗,容易造成数据写入延迟或者查询减慢。如果将master和client独立出来,一旦出现问题,重启后几乎是瞬间就恢复的,对用户几乎没有任何影响。另外将这些角色独立出来的以后,也将对应的计算资源消耗从data node剥离出来,更容易掌握data node资源消耗与写入量和查询量之间的联系,便于做容量管理和规划。
  2. 避免过高的并发,包括控制shard数量和threadpool的数量。在写入量和查询性能能够满足的前提下,为索引分配尽量少的分片。分片过多会带来诸多负面影响,例如:每次查询后需要汇总排序的数据更多;过多的并发带来的线程切换造成过多的CPU损耗;索引的删除和配置更新更慢Issue#18776; 过多的shard也带来更多小的segment,而过多的小segment会带来非常显著的heap内存消耗,特别是如果查询线程配置得很多的情况下。 配置过大的threadpool更是会产生很多诡异的性能问题Issue#18161里所描述的问题就是我们所经历过的。 默认的Theadpool大小一般来说工作得很不错了。
  3. 冷热数据最好做分离。对于日志型应用来说,一般是每天建立一个新索引,当天的热索引在写入的同时也会有较多的查询。如果上面还存有比较长时间之前的冷数据,那么当用户做大跨度的历史数据查询的时候,过多的磁盘IO和CPU消耗很容易拖慢写入,造成数据的延迟。所以我们用了一部分机器来做冷数据的存储,利用ES可以给结点配置自定义属性的功能,为冷结点加上"boxtype":"weak"的标识,每晚通过维护脚本更新冷数据的索引路由设置index.routing.allocation.{require|include|exclude},让数据自动向冷结点迁移。 冷数据的特性是不再写入,用户查的频率较低,但量级可能很大。比如我们有个索引每天2TB,并且用户要求保持过去90天数据随时可查。保持这么大量的索引为open状态,并非只消耗磁盘空间。ES为了快速访问磁盘上的索引文件,需要在内存里驻留一些数据(索引文件的索引),也就是所谓的segment memory。稍微熟悉ES的同学知道,JVM heap分配不能超过32GB,对于我们128GB RAM, 48TB磁盘空间的机器而言,如果只跑一个ES实例,只能利用到32GB不到的heap,当heap快用饱和的时候,磁盘上保存的索引文件还不到10TB,这样显然是不经济的。 因此我们决定在冷结点上跑3个ES实例,每个分配31GB heap空间,从而可以在一台物理服务器上存储30多TB的索引数据并保持open状态,供用户随时搜索。 实际使用下来,由于冷数据搜索频率不高,也没有写入,即时只剩余35GB内存给os做文件系统缓存,查询性能还是可以满足需求的。
  4. 不同数据量级的shard最好隔离到不同组别的结点。 大家知道ES会自己平衡shard在集群的分布,这个自动平衡的逻辑主要考量三个因素。其一同一索引下的shard尽量分散到不同的结点;其二每个结点上的shard数量尽量接近;其三结点的磁盘有足够的剩余空间。这个策略只能保证shard数量分布均匀,而并不能保证数据大小分布均匀。 实际应用中,我们有200多种索引,数据量级差别很大,大的一天几个TB,小的一个月才几个GB,并且每种类型的数据保留时长又千差万别。抛出的问题,就是如何能比较平衡并充分的利用所有节点的资源。 针对这个问题,我们还是通过对结点添加属性标签来做分组,结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点,使得每个组内结点上的数据量比较容易自动平衡。
  5. 定期做索引的force merge,并且最好是每个shard merge成一个segment。前面提到过,heap消耗与segment数量也有关系,force merge可以显著降低这种消耗。 如果merge成一个segment还有一个好处,就是对于terms aggregation,搜索时无需构造Global Ordinals,可以提升聚合速度。


四. 版本选择
我们在2.4版本上稳定跑了很长时间,比较保守的同学可以上2.4,激进有精力折腾的可以考虑最新的5.0。 我们集群两周前从v2.4.0升级到了v5.0.0这个版本,除了升级第一周遇到一个不稳定的问题以外,感觉新版本带来的以下特性还是非常值得去升级的:
  • 结点启动的Bootstrap过程加入了很多关键系统参数设置的核验,比如Max File Descriptors, Memory Lock, Virtual Memory设置等等,如果设置不正确会拒绝启动并抛出异常。 与其带着错误的系统参数启动,并在日后造成性能问题,不如启动失败告知用户问题,是个很好的设计!
  • 索引性能提升。升级后在同样索引速率下,我们看到cpu消耗下降非常明显,除了对索引速率提升有帮助,也会一定程度提升搜索速率。
  • 新的数值型数据结构,存储空间更小,Range和地理位置计算更快速
  • Instant Aggregation对于类似now-7d to now这样的范围查询聚合能够做cache了,实际使用下来,效果明显,用户在Kibana上跑个过去一周数据的聚合,头2次刷新慢点,之后有cache了几乎就瞬间刷出!
  • 更多的保护措施保证集群的稳定,比如对一次搜索hit的shard数量做了限制,增强了circuit breaker的特性,更好的防护集群资源被坏查询耗尽。


升级第一周,我们的冷数据结点出现间歇性不响应问题,从而刨出3个issue提交给官方:
Issue#21595 Issue#21612 Issue#21611
第一个问题确认为Bug,将在5.0.2修复,其他两个目前还不清楚根源,看起来也只在我们的应用场景里遇到了。所幸问题都找到了了规避措施,实施这些措施以后,最近一周我们的集群重新回到以前2.4版本时期的稳定状态。


五. 监控
不差钱没空折腾的建议还是买官方的xpack省心,有精力折腾的,利用ES各种丰富的stats api,用自己熟悉的监控工具采集数据,可视化出来就好了。 那么多监控指标,最最关键的还是以下几类:
  1. 各类Thread pool的使用情况,active/queue/reject可视化出来。 判断集群是否有性能瓶颈了,看看业务高峰期各类queue是不是很高,reject是不是经常发生,基本可以做到心里有数。
  2. JVM的heap used%以及old GC的频率,如果old GC频率很高,并且多次GC过后heap used%几乎下不来,说明heap压力太大,要考虑扩容了。(也有可能是有问题的查询或者聚合造成的,需要结合用户访问记录来判断)。
  3. Segment memory大小和Segment的数量。节点上存放的索引较多的时候,这两个指标就值得关注,要知道segment memory是常驻heap不会被GC回收的,因此当heap压力太大的时候,可以结合这个指标判断是否是因为节点上存放的数据过多,需要扩容。Segement的数量也是比较关键的,如果小的segment非常多,比如有几千,即使segment memory本身不多,但是在搜索线程很多的情况下,依然会吃掉相当多的heap,原因是lucene为每个segment会在thread local里记录状态信息,这块的heap内存开销和(segment数量* thread数量)相关。
  4. 很有必要记录用户的访问记录。我们只开放了http api给用户,前置了一个nginx做http代理,将用户第三方api的访问记录通过access log全部记录下来。通过分析访问记录,可以在集群出现性能问题时,快速找到问题根源,对于问题排查和性能优化都很有帮助。


最后就是多上手实践,遇到问题多查官方资料,多Google看是否有其他人遇到同类问题,精力充足有编程背景的同学也可以多刨刨源码。

[尊重社区原创,转载请保留或注明出处]
本文地址:http://elasticsearch.cn/article/110


83 个评论

全部的干货,辛苦wood叔。
指导路线,对我帮助很大
不错
太赞了,携程真是大家大业哇,集群规模如此之大
很有借鉴意义~~~~~谢谢分享!
学习了。。太感谢wood叔了
太感谢了,学习了
来自实战经验的分享,很值得收藏。准备把冷热分离做到我们现在的环境中去~~
很有借鉴意义。
请问下你们日志模糊搜索是用的分词么?
模糊搜索是需要搜索分词字段的
结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点,使得每个组内结点上的数据量比较容易自动平衡。

分级能举个例子么,是按 shard 的大小分?
我思考了下,这样反而好像会浪费机器
举个例子
curl -s x.6x.7x.11:9200/_cat/shards\?bytes=b|awk '/hot/{if ($6 >10737418240) print $1}'|awk -F '-' '{print $1}'|sort -nr|uniq -c
16 opxs_doxlog
58 opxs_dxct
192 xys_xxp

xys_xxp 这个索引原来分摊在 7 个节点上,可能每个节点该索引的分片数有一些差距,如果做了 shard 精细控制,只分配到 5台机器上,那么每个节点的该索引分片数平均了,但是由于节点的减少,每个节点上的该分配数增加了,这不是降低了查询性能?除非机器真的非常多?求 wood 叔叔指教
减少索引分配的结点,理论上是降低了查询性能,但也要视情况而定。当shard分配不均匀时,shard多的那个结点容易成为读写的热点,可能导致部分结点的空闲资源无法发挥作用。在结点数量不是很多的情况下,最好是设置索引的shard总量(primary+shard)是可用结点数量的整数倍,这样可以最大程度利用所有硬件资源。
写的真好!
少部分机器是刚上了不久的6块800GB SSD raid0 请问这样风险会不会太高?有没有考虑过使用 path data?

Segment memory大小和Segment的数量 对应的是 node stats segments": {
"count": 2632,
"memory": "2.1gb", 吗?怎么才算多和大?
多路径path data在某些场景下容易出现数据读写热点问题,并且一块盘坏了的时候,仍然需要停止服务更换, 极度不推荐。 raid0风险并不大,通过replica来保证高可用就可以了。

segment memory就是看上面这些数据, 多大才算大取决于分配的heap size有多大。 这些memory是常驻heap,不会被GC掉的,接近heap 50%的时候就需要比较重视了。因为index buffer, query cache, request cache,fielddata cache还要消耗一些内存(取决于集群的配置),还要留一些用于处理search request。 默认JVM设置下, heap消耗达到75%的时候就开始触发CMS GC回收老年代空间了。
谢谢回复,第一个问题单盘 ssd io 应该就比较给力了,未来的规模应该也在四五十台左右,主要怕同时几台机 raid0 坏掉的情况。而坏一块盘只用恢复上面分片就可以了,所以我也在纠结,目前还没发生过坏盘情况。

第二个 segment 那我们这不大才2g
不同数据量级的shard最好隔离到不同组别的结点;
不同请求量级的索引是否也需要隔离到不同组别的节点?
隔离到不同组别的节点怎么操作,是否有相关的文档?
ES的node是可以增加属性标识的,然后可以根据这些标识进行索引的shard分配设置。 具体参考: https://www.elastic.co/guide/en/elasticsearch/reference/5.4/shard-allocation-filtering.html
谢谢啦, 我去研究下
请问你们目前还是使用的niofs么?
是的,我们依然在使用niofs。 即使现在集群升级到5.3.2,我们发现使用默认的mmapfs, 在部署多个实例的机器上对大索引做terms aggregation时, 搜索线程会长时间构造global ordinals,其间磁盘读IO非常高,可以持续数十分钟。 一旦改为niofs,问题就没有了。
查询响应时间百分位 75%:0.160s 90%:1.640s 95%:6.691s 99%:14.0039s

这个统计粒度是通过访问 api 统计?粒度有多细?到索引级别吗?
这个统计是集群对集群所有的api调用,但是统计可以精细到索引级别。 因为我们对于ES集群的访问都是通过nginx过来的,统计数据来自于nginx的access log。
谢谢。同时请教下大神 master节点和data节点按一个什么样的比例设置啊,譬如我有50台服务器,设置多少台master节点,多少台data节点比较合适?
master 3台就够了, 管理50个结点的集群没什么问题,具体 data 结点需要多少,要根据数据量扩充。
请问master节点需要怎样的硬件配置?
master本身不是很消耗资源,4core/8GB RAM的虚拟机足够
赞!相当给力的,在继续研究一下
如果所有的master都挂掉了,data node能正常接收访问请求吗,这个动作是如何实现的呢
客户端配置,需要写上master的ip和端口吗
你好,现在5台机器,每个机器1个master,3个data 节点(256G内存,12G(主)+55G*3(data 节点)); 索引分片数30, 每天全量从hbase hfile批量插入2T数据到es,要跑11个小时,查看日志是磁盘IO过高,准备做raid0;请问内存配置是否合理呢,还有其他建议没?谢谢了
大量写入对磁盘IO要求还是比较高的,多块磁盘做raid0很有必要。 另外这篇文档https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html 基本上总结了所有和写入相关的优化点,看一下是否有帮助。

内存方面, data结点的55GB如果是指heap的话,那分的有点高了,分配31GB左右就可以,因为超过32GB以后,JVM的对象指针压缩失效,实际可能内存反而更小。 除了浪费内存以外,过大的内存对应的GC耗时也增加。
(每个机器1个master节点,12G内存,4个data节点,31G*4内存) 留给底层Lucene:256-31*4-12=120G, 加一个data节点,充分利用内存,4个31G; 这样配置是否合理了? 多path.data不敢用
(每个机器1个master节点,12G内存,4个data节点,31G*4内存) 留给底层Lucene:256-31*4-12=120G, 加一个data节点,充分利用内存,4个31G; 这样配置是否合理了? 多path.data不敢用
这样可以的,只是这么多实例,大量写入情况下,对磁盘IO能力要求比较高。
您好,网上有很多文章提到单个ES集群的数据量达到一定规模会导致性能下降的问题,但也没有明确的求证,所以想咨询一下,有必要搞多个集群吗?
(8台 8核32G 500G硬盘机器,预计初步存的数据量在 2T 左右)
单个集群数据量大到一定程度后,主要是集群状态数据的更新, 例如创建/删除索引,更新mapping等操作会变慢。 合理规划集群负载的情况下, 索引速度和查询速度并不会下降。

8台机器,2TB数据单集群就可以了, 没有必要划分多个集群。
1. 一个3T左右的数据量在两台机器上(12核,128G ram),应该如何设置节点数,以及如何配置,我当前的设置是1个master,1个client,3个dataNode,dataNode的内存设置为20G, master 4G, client 15G,不知道是否合理?
2. 是否有必要对ES来购买单独的服务器来存储,其它的数据库不在ES的服务器上;
cluster.name: index_es
node.name: "es_node1-1"
transport.tcp.port: 9400
node.master: false
node.data: true
http.enabled: false
network.host: xx.xx.xx.xx

path.data: /data1/elasticsearch/data1,/data2/elasticsearch/data1,/data3/elasticsearch/data1,/data4/elasticsearch/data1
path.logs: /data1/elasticsearch/logs1

bootstrap.memory_lock: true
transport.tcp.compress: true
discovery.zen.ping.multicast.enabled: false
discovery.zen.minimum_master_nodes: 2
discovery.zen.ping.unicast.hosts: ["xx.xx.xx.xx:9300","xx.xx.xx.xx:9300","xx.xx.xx.xx:9300","xx.xx.xx.xx:9300","xx.xx.xx.xx:9300","xx.xx.xx.xx:9300","xx.xx.xx.xx:9300","xx.xx.xx.xx:9300"]
indices.store.throttle.max_bytes_per_sec : 800mb
indices.cache.filter.size: 50%

discovery.zen.ping.timeout: 120s
discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 8
discovery.zen.fd.ping_interval: 30s

client.transport.ping_timeout: 120s
client.transport.nodes_sampler_interval: 30s
index.translog.flush_threshold_size: 2000mb
index.translog.flush_threshold_period: 120m
index.translog.interval: 60m
index.translog.flush_threshold_ops: 100000
index.cache.field.max_size: 50000
index.cache.field.expire: 10m
index.cache.field.type: soft
indices.breaker.fielddata.limit: 50%
indices.memory.index_buffer_size: 50%
indices.fielddata.cache.size: 50%
processors: 10
index.mapping.nested_fields.limit: 1001


大神,这是线上ES 2.4.2的yml配置,1.6升级过来的,没做多大改动,集群是3台master+5台node(每台6T磁盘,12块盘,radi0,256G内存,配置3个节点,31G*3 heap),每天BulkProcessor全量写入ES集群数据量2T多左右,比较慢,请问这个配置哪里可以优化的吗?
只有两台机器做成的集群无法容忍故障,只要挂一台机器集群就处于不可用状态,最好至少弄3台机器。 机器比较少的情况下,master, client不用单独划分出来,可以和data node共用。 所以就是3个node,同时都是master,client,data,内存配置30GB。 对性能要求高的话,ES应该用单独的服务器来不熟,不要和其他数据库混布。
谢谢回复! 是的,因为硬件紧张,现在数据都极少使用副本,一出问题集群就不可用!
您好,请问下冷数据节点的问题。如您说的,128G内存,跑3个31G实例,剩余35GB内存给os做文件系统缓存。官网说最好留50%给lucene缓存,这个50%就是java的堆外内存默认的配置么(跟heap一样大)。如果是的话,这样假如数据太大,directMemory会导致系统内存不够用?
另外,假如我系统有足够的内存,但是数据量实在太大,lucene缓存的数据有限,这时候,假如我系统还有内存,给系统做 os memory cache,其实查询效率也可以,也不太消耗io?
50%就是留给java堆外用的, 会被directMemory, memory mapped buffer, os page cache用到。 DirectMemory主要是netty在通信层面用到,消耗主要是取决于网络上请求的大小,比如比较bulk size的大小和并发量可能会决定这块的消耗。 DirectMemory会在full GC触发的时候被回收掉,一般不会导致内存不够。 我们只有在生产上见过一个特殊的例子,就是索引数据量小,但是并发搜索量很高的应用,由于产生的对象大多被YGC回收了,少量drectmemory buffer对象进入到老年代,而老年代又回收周期非常长(好几天才一次),导致堆外的DMB一直在泄漏。 我们改为G1后,问题就解决了。 你说的lucene缓存需求,是对mmaped buffer的使用,这块和DirectMemory是两回事。 如果查询的数据量很大,堆外内存不够的时候,os 会自动evict掉一些不常用的buffer,回收内存。 我们之前冷数据结点在部署多个实例,大片数据聚合速度缓慢的原因后来发现和堆外留的内存太少相关。 5.0以后完全依赖mmaped buffer读取索引文件,在堆外可用的buffer太少的时候,大片数据的读取可能导致过于频繁的内存换出换入。 所以对于查询速度有要求的话,建议遵从官方建议,预留的堆外内存最好不少于heap的分配量。
请问单台服务器是怎样实现多个ES实例安装的,是否可以实现5台服务器安装10个节点的集群?谢谢
请问JDK1.8版本的G1回收器是否稳定,官网提示最好不要用G1,可能有bug,所以一直不敢更换CMS.
1.8的小版本有要求,官方建议1.8.0_131以上的版本。 ES5i 后的版本,启动过的时候会做版本检查,如果使用的是已知的问题版本,会拒绝启动。
很赞
您好,3台es的话,是不是一台单作为主节点,一台作为主节点和数据节点,还有一台作为数据几点
3台ES就不用区分角色了,3台都可以做master , data node
特意登录上来,手动点赞,wood有github账号么?只为follow。我们数据量大概40亿
我不做开发,github上啥都没有,follow我没有价值呀。 :)
看你star什么。哈哈
你不注意观察啊,这篇文章的github issue链接里,都是我的踪影
据我观察,你们组有两个人
找到了。真低调
您好,请问如果我有80台机器(32G),不知道我的master、client、data节点该按照什么比例分配呢?
master 3个够了, client可以先配置3-5个,根据实际负载情况增减,其他做data node。
再请教个问题哈,5亿的全量数据,然后每天都还有增量数据更新,您说我是否要考虑多个es集群呢?如果用1个集群的是否会有瓶颈?
80台机器,经验值, 一个集群没啥问题,机器上百台以后才开始考虑分多集群。
好的 谢谢
您好,集群8台服务器,ssd的,内存在128g以上,请问该如何规划master、client以及data 节点?
集群的机器数量不多,又都是高配机器, 单独设立master,client就比较浪费了,不要区分角色直接混用吧。 如果条件允许,弄几台磁盘配置不高的虚拟机跑master和client就够了。
@wood 大神,想咨询一下,目前我们的集群是3台 16C 96G内存,磁盘12T*4 (raid5)的配置,为了利用内存,就每台放了两个数据节点,目前大约有4T的数据
前几天,线上出现CPU突增到100%的情况,学习了您之前发的文章,发现是用 模糊匹配导致的。但是也有另外一个疑问,目前我们这样机器配置,CPU或者内存是否够用呢?
CPU或者内存是否够用,要根据业务高峰期时查询响应时间,cpu占用率,gc频率,磁盘IO利用率等监控指标,结合业务的期望综合判断。 如果查询很慢,同时某项指标过高,可能就是资源不太够用。 (当然首先应该排查是否有消耗过高的查询可以优化)

如果是对查询响应速度有较高要求的话,一台机器跑一个实例更好,CPU,内存磁盘IO足以被一个实例全部有效利用。单机跑多实例,一般是期望能存放更多的数据,这时候往往对于查询响应速度要求不是非常苛刻。
wood大神,一个机器上面部署多个冷节点,如何保证一个shard的主和副本不落在同一台机器上面?Shard Allocation Awareness吗?
设置cluster.routing.allocation.same_shard.host: true 即可。
谢谢
wood大神,集群运行一段时间后,master节点heap会耗尽,每次必须重启,有什么办法么,一台master 多台data
master heap耗尽一般都是因为集群状态数据过大造成的。 短期如果有大量的状态更新任务产生,比如增删索引、更新mapping、或者有结点脱离触发了recovery,master可能处理不过来,造成大量的任务堆积,消耗大量的内存。
问题的解决要从几方面着手:
1. 确保集群索引,结点书和 shard数量不能过多,根据经验单集群结点数尽量控制在100个以内,shard数量尽量控制在1万个以内为好。
2. 尽量不要使用动态mapping,容易在数据写入过程中,产生大量的update mapping任务。
3. 尽量采用新一点的ES版本,比如5.6.x或者6.4.x, 6.5.x。 早期的某些版本,master在处理tasks超时方面有bug,遇到大量任务需要处理的情况下,产生内存泄漏。
多谢指点,我现在用的还是2.2的一直没有更新过
2.2的确有些老了,master本身应该就有一些稳定性问题,推荐升级到5.6以上版本,稳定性高很多。
wood大神好,麻烦问下以下这种情况有什么好的建议嘛
我们现在有12台服务器,128G内存,16核
每个机器两个节点实例,3个Matser ,21个data,42个分块,2副本。
但是总体数据量较小 只有600G左右,每月数据增量也就7G左右。
总数据条数在3000万左右,问题在于查询的并发量比较大,每天大概会有500多万次的查询请求,而且时间段集中在上班的8小时中,更大的问题是会有很多模糊查询甚至是通配符查询(业务的确有需要),且查询字段较多。
请问针对查询效率,以上情况有没有什么好的优化方案和建议呢,拜谢
这个数据量级,不建议机器上跑2个实例,只跑一个实例的性能会更好。 实在需要模糊查询,则尽量避免前置通配符的查询。 通常来说模糊查询可以通过分词(比方利用ngram)来达到类似的查询效果,并提升性能。
只跑一个实例的话 128G内存是不是太浪费了 我们都是实体机
剩下的内存不会浪费,会被用于文件系统缓存,可以提高集群的搜索性能。 由于性能是你的主要关注点,所以我认为1个实例是更好的选择。
好的 我测试下 多谢
wood大神好,再次来这封帖子下提问。我们现有的集群需要扩容,倾向于用Docker容器,为了扩容方便,可能会用相对小规模的机器,例如 4C 8G 或者 8C 16G的机器,通过横向扩展来达到目的,预计会用到 20-30台机器,数据量在 10T左右。
疑问点在于:小规模机器能否满足ES生产环境的需要?有哪些需要注意的地方。。
盼回复,感谢~~
你这个问题很难回答,能否满足需要,是要看具体业务应用场景对集群响应速度,吞吐能力的期望,建议自己做性能测试找答案。
好的,谢谢了。
wood大叔你好,有个问题想请教您一下,我用ES主要用途是用来给客户搜索各种数据的,然后现在用的是Solr需要替换到es上,但是我现在手上的硬件环境是两台40vcoreCPU + 576GB RAM,一台32vcoreCPU + 384GB RAM这样的三台物理机,然后根据现在的solr得出来每天查询有150W条,然后所有索引加起来总的数据有1T左右,我经过我查询各种文档和其他人发的博客等信息就是jvm heap一些限制, 也去了解了堆外内存,然后还有G1垃圾回收器,然后有方案是一台机器上多个节点,但是会影响查询性能,所以最终决定是3台物理机做3个master+data节点,然后再找一台机器虚拟机做单做master,这样四个节点的方案,所以我很想向您问一下,根据您的经验这样的方案,然后所有的节点的JVM内存都设置为30GB,会出现OOM的问题吗,因为solr不是我接手的,所以不是很了解,但是前面的人设置的solr的堆内存很大有270GB,我也稍微改动过然后就会出现OOM的现象,我很担心我现在几台机器只设置30G的堆内存也会出现这种情况,所以请您指导一下,然后我现在的ES版本是7.3,java 11,根据G1的特性我是不是也可以把堆内存加大一点呢?

要回复文章请先登录注册