两台机器，每台上面两个节点（似乎没有这个必要），32G的机器上面两个节点分别分配了4G内存，64G节点上面两个节点分别分配了8G内存。
之前日志数据解析后放入一个单索引中，索引为12个分片，0备份，无刷新。
在索引数据量达到一定时（大概300G左右），bulk的速度变得很缓慢，同时两台机器的ES进程的CPU%数值降低，尤其是64G的那台机器，几乎不占用CPU。
后了解到日志类的数据，推荐基于日期管理的索引，索引现在更改为按天生成索引，分片依旧12个，0副本，但是在索引数目达到40左右（每个索引50G左右的数据），数据量1.4TB时，再次出现以上相同情况，尝试关闭了几个数十G容量的索引，性能恢复，情况再发生时又尝试关闭了几个数M容量的索引则不能恢复，继续关闭大容量索引临时解决bulk缓慢的问题。
了解到对索引进行optimize操作，将segments整理为一个会降低相应索引的资源占用，于是进行该操作（50G左右大小的索引），但是许久未有结果返回...
现在我不太清楚问题出在哪里了，似乎是数据量带来的问题？但是1.4TB的容量算多吗？
→ [_cluster/stats](http://git.oschina.net/sephen/ ... /stats) 信息。
集群变缓慢时的hot_threads信息忘记保存了...
如果需要其他相关信息请指出~ 望各位前辈解惑 ：）
————————————————————————
PS：
每条文档所有字段长度和为80左右。
当前稳定状态下的性能为，1400W条文档（1G+）时间<5min
————————————————————————
2015-02-26 10:18:50更新，上文所述的optimize操作在一小时后终于完成了：
2015-02-26 09:01:01 INFO <Indices management module started.>
2015-02-26 09:01:01 INFO <Optimize index : ossdatabse-2015-02-21>
2015-02-26 09:01:01 INFO <Result:{"_shards":{"total":12,"successful":12,"failed":0}}>
2015-02-26 10:11:49 INFO <Indices management module end.>
之前日志数据解析后放入一个单索引中，索引为12个分片，0备份，无刷新。
在索引数据量达到一定时（大概300G左右），bulk的速度变得很缓慢，同时两台机器的ES进程的CPU%数值降低，尤其是64G的那台机器，几乎不占用CPU。
后了解到日志类的数据，推荐基于日期管理的索引，索引现在更改为按天生成索引，分片依旧12个，0副本，但是在索引数目达到40左右（每个索引50G左右的数据），数据量1.4TB时，再次出现以上相同情况，尝试关闭了几个数十G容量的索引，性能恢复，情况再发生时又尝试关闭了几个数M容量的索引则不能恢复，继续关闭大容量索引临时解决bulk缓慢的问题。
了解到对索引进行optimize操作，将segments整理为一个会降低相应索引的资源占用，于是进行该操作（50G左右大小的索引），但是许久未有结果返回...
现在我不太清楚问题出在哪里了，似乎是数据量带来的问题？但是1.4TB的容量算多吗？
→ [_cluster/stats](http://git.oschina.net/sephen/ ... /stats) 信息。
集群变缓慢时的hot_threads信息忘记保存了...
如果需要其他相关信息请指出~ 望各位前辈解惑 ：）
————————————————————————
PS：
每条文档所有字段长度和为80左右。
当前稳定状态下的性能为，1400W条文档（1G+）时间<5min
————————————————————————
2015-02-26 10:18:50更新，上文所述的optimize操作在一小时后终于完成了：
2015-02-26 09:01:01 INFO <Indices management module started.>
2015-02-26 09:01:01 INFO <Optimize index : ossdatabse-2015-02-21>
2015-02-26 09:01:01 INFO <Result:{"_shards":{"total":12,"successful":12,"failed":0}}>
2015-02-26 10:11:49 INFO <Indices management module end.>
5 个回复
唯一 - 等
赞同来自: 九月痕 、Rubricate 、kuku1314520
tonylxc - You know, search
赞同来自: 九月痕 、Rubricate 、kuku1314520
2. 大数据下, 请考虑使用Master, Data, Client 3类型node模式. 一般是3~5 master nodes, N data nodes, 3 client node. bulk索引时, 请求发给data nodes. 搜索时, 请求发给client node.
3. 我曾做过跟你类似的数据量, 1TB+, 分布在3 master nodes, 10 data nodes共13个box, 运行在AWS, 每box有60G内存, 其中30G分配给elasticsearch. bulk索引时未见性能下降. filter及aggs搜索时间依然在100ms左右.
4. 0副本节省空间, 但有损于搜索, 建议至少1 replica.
5. 磁盘建议使用SSD, 但是如果只能用spinning, 请用最快速的 (比如7200或10k转)
6. 建议定时抓取node status, 写入graphite, 转化为图表来分析病症, 做优化, 做对比. (Github的全code搜索ES cluster就是这么干的)
rockybean - Elastic Certified Engineer, ElasticStack Fans，公众号：ElasticTalk
赞同来自: Rubricate 、九月痕 、kuku1314520
你有去看es的输出日志吗？有无严重gc？
三斗室 - ELK
赞同来自: 九月痕 、Rubricate
按照时间分索引后，不再当前写入期内的索引，可以关闭bloom filter，这个可以释放将近三分之一的内存占用。你有做这个么？或者使用最新的ES版本，默认关闭了这个。
有其他日志么？会不会有OOM之类的发生？
qq123 - 90后IT精英
赞同来自: kuku1314520