【携程旅行网 吴晓刚】
ElasticSearch目前在互联网公司主要用于两种应用场景，其一是用于构建业务的搜索功能模块且多是垂直领域的搜索，数据量级一般在千万至数十亿这个级别；其二用于大规模数据的实时OLAP，经典的如ELKStack，数据规模可能达到千亿或更多。 这两种场景的数据索引和应用访问模式上差异较大，在硬件选型和集群优化方面侧重点也会有所不同。一般来说后一种场景属于大数据范畴，数据量级和集群规模更大，在管理方面也更有挑战。
应Medcl大大的邀请，为ES中文社区做今年的Advent开篇，分享一下我在管理自家公司用于日志分析的ES集群方面的一点心得，蜻蜓点水，泛泛而谈，希望大方向上能对大家提供一些帮助。
这里的自家，即是携程旅行网。从2013年开始接触ES，我们团队先后实践过0.9.x -> 5.0.0中间各个版本，从最初只用于运维内部IIS日志的分析，到如今支持IT、呼叫中心、安全、测试、业务研发等多个部门超过200种日志型数据的实时检索与分析。 一路走来，愉悦了大家，也死磕了自己。
目前我们最大的日志单集群有120个data node，运行于70台物理服务器上。数据规模如下:
运维这样大规模的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，主要目的是想做冷热数据分离，后面谈到集群架构的时候，再进一步解释一下如何利用硬件资源。
三. 集群的管理
四. 版本选择
我们在2.4版本上稳定跑了很长时间，比较保守的同学可以上2.4，激进有精力折腾的可以考虑最新的5.0。 我们集群两周前从v2.4.0升级到了v5.0.0这个版本，除了升级第一周遇到一个不稳定的问题以外，感觉新版本带来的以下特性还是非常值得去升级的:
升级第一周，我们的冷数据结点出现间歇性不响应问题，从而刨出3个issue提交给官方:
Issue#21595 Issue#21612 Issue#21611
第一个问题确认为Bug，将在5.0.2修复，其他两个目前还不清楚根源，看起来也只在我们的应用场景里遇到了。所幸问题都找到了了规避措施，实施这些措施以后，最近一周我们的集群重新回到以前2.4版本时期的稳定状态。
五. 监控
不差钱没空折腾的建议还是买官方的xpack省心，有精力折腾的，利用ES各种丰富的stats api，用自己熟悉的监控工具采集数据，可视化出来就好了。 那么多监控指标，最最关键的还是以下几类:
最后就是多上手实践，遇到问题多查官方资料，多Google看是否有其他人遇到同类问题，精力充足有编程背景的同学也可以多刨刨源码。
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，主要目的是想做冷热数据分离，后面谈到集群架构的时候，再进一步解释一下如何利用硬件资源。
三. 集群的管理
- 首先很有必要对ES的结点做角色划分和隔离。大家知道ES的data node除了放数据以外，也可以兼任master和client的角色，多数同学会将这些角色混入到data node。然而对于一个规模较大，用户较多的集群，master和client在一些极端使用情况下可能会有性能瓶颈甚至内存溢出，从而使得共存的data node故障。data node的故障恢复涉及到数据的迁移，对集群资源有一定消耗，容易造成数据写入延迟或者查询减慢。如果将master和client独立出来，一旦出现问题，重启后几乎是瞬间就恢复的，对用户几乎没有任何影响。另外将这些角色独立出来的以后，也将对应的计算资源消耗从data node剥离出来，更容易掌握data node资源消耗与写入量和查询量之间的联系，便于做容量管理和规划。
- 避免过高的并发，包括控制shard数量和threadpool的数量。在写入量和查询性能能够满足的前提下，为索引分配尽量少的分片。分片过多会带来诸多负面影响，例如：每次查询后需要汇总排序的数据更多；过多的并发带来的线程切换造成过多的CPU损耗；索引的删除和配置更新更慢Issue#18776; 过多的shard也带来更多小的segment，而过多的小segment会带来非常显著的heap内存消耗，特别是如果查询线程配置得很多的情况下。 配置过大的threadpool更是会产生很多诡异的性能问题Issue#18161里所描述的问题就是我们所经历过的。 默认的Theadpool大小一般来说工作得很不错了。
- 冷热数据最好做分离。对于日志型应用来说，一般是每天建立一个新索引，当天的热索引在写入的同时也会有较多的查询。如果上面还存有比较长时间之前的冷数据，那么当用户做大跨度的历史数据查询的时候，过多的磁盘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做文件系统缓存，查询性能还是可以满足需求的。
- 不同数据量级的shard最好隔离到不同组别的结点。 大家知道ES会自己平衡shard在集群的分布，这个自动平衡的逻辑主要考量三个因素。其一同一索引下的shard尽量分散到不同的结点;其二每个结点上的shard数量尽量接近;其三结点的磁盘有足够的剩余空间。这个策略只能保证shard数量分布均匀，而并不能保证数据大小分布均匀。 实际应用中，我们有200多种索引，数据量级差别很大，大的一天几个TB，小的一个月才几个GB，并且每种类型的数据保留时长又千差万别。抛出的问题，就是如何能比较平衡并充分的利用所有节点的资源。 针对这个问题，我们还是通过对结点添加属性标签来做分组，结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点，使得每个组内结点上的数据量比较容易自动平衡。
- 定期做索引的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，用自己熟悉的监控工具采集数据，可视化出来就好了。 那么多监控指标，最最关键的还是以下几类:
- 各类Thread pool的使用情况，active/queue/reject可视化出来。 判断集群是否有性能瓶颈了，看看业务高峰期各类queue是不是很高，reject是不是经常发生，基本可以做到心里有数。
- JVM的heap used%以及old GC的频率，如果old GC频率很高，并且多次GC过后heap used%几乎下不来，说明heap压力太大，要考虑扩容了。（也有可能是有问题的查询或者聚合造成的，需要结合用户访问记录来判断)。
- Segment memory大小和Segment的数量。节点上存放的索引较多的时候，这两个指标就值得关注，要知道segment memory是常驻heap不会被GC回收的，因此当heap压力太大的时候，可以结合这个指标判断是否是因为节点上存放的数据过多，需要扩容。Segement的数量也是比较关键的，如果小的segment非常多，比如有几千，即使segment memory本身不多，但是在搜索线程很多的情况下，依然会吃掉相当多的heap，原因是lucene为每个segment会在thread local里记录状态信息，这块的heap内存开销和(segment数量* thread数量)相关。
- 很有必要记录用户的访问记录。我们只开放了http api给用户，前置了一个nginx做http代理，将用户第三方api的访问记录通过access log全部记录下来。通过分析访问记录，可以在集群出现性能问题时，快速找到问题根源，对于问题排查和性能优化都很有帮助。
最后就是多上手实践，遇到问题多查官方资料，多Google看是否有其他人遇到同类问题，精力充足有编程背景的同学也可以多刨刨源码。
[尊重社区原创，转载请保留或注明出处]
本文地址：http://elasticsearch.cn/article/110
本文地址：http://elasticsearch.cn/article/110
83 个评论
全部的干货，辛苦wood叔。
指导路线，对我帮助很大
不错
太赞了，携程真是大家大业哇，集群规模如此之大
很有借鉴意义~~~~~谢谢分享！
学习了。。太感谢wood叔了
太感谢了，学习了
来自实战经验的分享，很值得收藏。准备把冷热分离做到我们现在的环境中去~~
很有借鉴意义。
请问下你们日志模糊搜索是用的分词么？
结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点，使得每个组内结点上的数据量比较容易自动平衡。
分级能举个例子么，是按 shard 的大小分？
分级能举个例子么，是按 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 叔叔指教
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", 吗？怎么才算多和大？
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回收老年代空间了。
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
第二个 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 统计？粒度有多细？到索引级别吗？
这个统计是集群对集群所有的api调用，但是统计可以精细到索引级别。 因为我们对于ES集群的访问都是通过nginx过来的，统计数据来自于nginx的access log。
谢谢。同时请教下大神 master节点和data节点按一个什么样的比例设置啊，譬如我有50台服务器，设置多少台master节点，多少台data节点比较合适？
请问master节点需要怎样的硬件配置？
赞！相当给力的，在继续研究一下
如果所有的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耗时也增加。
内存方面， 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 左右）
（8台 8核32G 500G硬盘机器，预计初步存的数据量在 2T 左右）
单个集群数据量大到一定程度后，主要是集群状态数据的更新， 例如创建/删除索引，更新mapping等操作会变慢。 合理规划集群负载的情况下， 索引速度和查询速度并不会下降。
8台机器，2TB数据单集群就可以了， 没有必要划分多个集群。
8台机器，2TB数据单集群就可以了， 没有必要划分多个集群。
1. 一个3T左右的数据量在两台机器上(12核，128G ram)，应该如何设置节点数，以及如何配置，我当前的设置是1个master,1个client,3个dataNode,dataNode的内存设置为20G, master 4G, client 15G，不知道是否合理？
2. 是否有必要对ES来购买单独的服务器来存储，其它的数据库不在ES的服务器上;
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多左右，比较慢，请问这个配置哪里可以优化的吗？
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？
另外，假如我系统有足够的内存，但是数据量实在太大，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节点该按照什么比例分配呢？
再请教个问题哈，5亿的全量数据，然后每天都还有增量数据更新，您说我是否要考虑多个es集群呢？如果用1个集群的是否会有瓶颈？
您好，集群8台服务器，ssd的，内存在128g以上，请问该如何规划master、client以及data 节点？
集群的机器数量不多，又都是高配机器， 单独设立master,client就比较浪费了，不要区分角色直接混用吧。 如果条件允许，弄几台磁盘配置不高的虚拟机跑master和client就够了。
@wood 大神，想咨询一下，目前我们的集群是3台 16C 96G内存，磁盘12T*4 （raid5）的配置，为了利用内存，就每台放了两个数据节点，目前大约有4T的数据
前几天，线上出现CPU突增到100%的情况，学习了您之前发的文章，发现是用 模糊匹配导致的。但是也有另外一个疑问，目前我们这样机器配置，CPU或者内存是否够用呢？
前几天，线上出现CPU突增到100%的情况，学习了您之前发的文章，发现是用 模糊匹配导致的。但是也有另外一个疑问，目前我们这样机器配置，CPU或者内存是否够用呢？
CPU或者内存是否够用，要根据业务高峰期时查询响应时间，cpu占用率，gc频率，磁盘IO利用率等监控指标，结合业务的期望综合判断。 如果查询很慢，同时某项指标过高，可能就是资源不太够用。 （当然首先应该排查是否有消耗过高的查询可以优化）
如果是对查询响应速度有较高要求的话，一台机器跑一个实例更好，CPU，内存磁盘IO足以被一个实例全部有效利用。单机跑多实例，一般是期望能存放更多的数据，这时候往往对于查询响应速度要求不是非常苛刻。
如果是对查询响应速度有较高要求的话，一台机器跑一个实例更好，CPU，内存磁盘IO足以被一个实例全部有效利用。单机跑多实例，一般是期望能存放更多的数据，这时候往往对于查询响应速度要求不是非常苛刻。
wood大神，一个机器上面部署多个冷节点，如何保证一个shard的主和副本不落在同一台机器上面？Shard Allocation Awareness吗？
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，遇到大量任务需要处理的情况下，产生内存泄漏。
问题的解决要从几方面着手:
1. 确保集群索引,结点书和 shard数量不能过多，根据经验单集群结点数尽量控制在100个以内，shard数量尽量控制在1万个以内为好。
2. 尽量不要使用动态mapping，容易在数据写入过程中，产生大量的update mapping任务。
3. 尽量采用新一点的ES版本，比如5.6.x或者6.4.x, 6.5.x。 早期的某些版本，master在处理tasks超时方面有bug，遇到大量任务需要处理的情况下，产生内存泄漏。
wood大神好，麻烦问下以下这种情况有什么好的建议嘛
我们现在有12台服务器，128G内存，16核
每个机器两个节点实例，3个Matser ,21个data,42个分块，2副本。
但是总体数据量较小 只有600G左右，每月数据增量也就7G左右。
总数据条数在3000万左右，问题在于查询的并发量比较大，每天大概会有500多万次的查询请求，而且时间段集中在上班的8小时中，更大的问题是会有很多模糊查询甚至是通配符查询（业务的确有需要），且查询字段较多。
请问针对查询效率，以上情况有没有什么好的优化方案和建议呢，拜谢
我们现在有12台服务器，128G内存，16核
每个机器两个节点实例，3个Matser ,21个data,42个分块，2副本。
但是总体数据量较小 只有600G左右，每月数据增量也就7G左右。
总数据条数在3000万左右，问题在于查询的并发量比较大，每天大概会有500多万次的查询请求，而且时间段集中在上班的8小时中，更大的问题是会有很多模糊查询甚至是通配符查询（业务的确有需要），且查询字段较多。
请问针对查询效率，以上情况有没有什么好的优化方案和建议呢，拜谢
这个数据量级，不建议机器上跑2个实例，只跑一个实例的性能会更好。 实在需要模糊查询，则尽量避免前置通配符的查询。 通常来说模糊查询可以通过分词(比方利用ngram)来达到类似的查询效果，并提升性能。
wood大神好，再次来这封帖子下提问。我们现有的集群需要扩容，倾向于用Docker容器，为了扩容方便，可能会用相对小规模的机器，例如 4C 8G 或者 8C 16G的机器，通过横向扩展来达到目的，预计会用到 20-30台机器，数据量在 10T左右。
疑问点在于：小规模机器能否满足ES生产环境的需要？有哪些需要注意的地方。。
盼回复，感谢~~
疑问点在于：小规模机器能否满足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的特性我是不是也可以把堆内存加大一点呢？
