有个人长的像洋葱,走着走着就哭了…….

集群稳定性的一些问题(一定量数据后集群变得迟钝)

Elasticsearch | 作者 九月痕 | 发布于2015年02月26日 | 阅读数:16584

两台机器,每台上面两个节点(似乎没有这个必要),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.>
已邀请:

唯一 -

赞同来自: 九月痕 Rubricate kuku1314520

首先,你写入的时候要确定内存的使用量如何,不过一般写入内存的使用不会消耗太大。就算是bulk,也只是用一点内存缓冲而已。。。我不知道你的es的磁盘情况如何,es的写入数据是顺序存储,但是在es里面存在大量的索引,这些索引在维护和写入的时候,锁的情况还有随机IO的消耗都很明显,所以我觉得你的瓶颈更多可能是在磁盘。可以分享下磁盘的情况再讨论~

tonylxc - You know, search

赞同来自: 九月痕 Rubricate kuku1314520

1. Elasticsearch最好运行在per node per box. 多node共享一个box会造成内存竞争, 而且难查错 (到底是哪个node crazy了呢?). 不推荐.
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

我现在的配置是3个master,4个data,2个client。data的内存都是分配了32GB,每天20GB的数据量,使用bulk索引,目前没有遇到性能问题。

你有去看es的输出日志吗?有无严重gc?

三斗室 - ELK

赞同来自: 九月痕 Rubricate

没细看,不过为啥你的node给内存这么少呢~另外,es的nodes之间就是简单轮过去分数据的,所以如果每个nodes之间的硬件配置不统一,那么短板的那个会影响全局的。

按照时间分索引后,不再当前写入期内的索引,可以关闭bloom filter,这个可以释放将近三分之一的内存占用。你有做这个么?或者使用最新的ES版本,默认关闭了这个。


有其他日志么?会不会有OOM之类的发生?

qq123 - 90后IT精英

赞同来自: kuku1314520

大批量写数据的时候 建议去掉副本 这样写的速度要快很多  还可以把一些索引暂时关掉腾出内存

要回复问题请先登录注册