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

es5.1.2,cpu占用率高,节点失联,进程未挂

回复

lbx6z 发起了问题 • 1 人关注 • 0 个回复 • 2752 次浏览 • 2018-06-14 23:32 • 来自相关话题

elasticseach丢字段

回复

taowang7 发起了问题 • 1 人关注 • 0 个回复 • 1824 次浏览 • 2018-06-14 18:42 • 来自相关话题

请教一个搜索结果的汇总统计的问题

wen 回复了问题 • 5 人关注 • 3 个回复 • 1760 次浏览 • 2018-06-15 10:26 • 来自相关话题

关于Elasticsearch查询出结果再运算排序的问题

laoyang360 回复了问题 • 4 人关注 • 3 个回复 • 4814 次浏览 • 2018-06-17 00:19 • 来自相关话题

filebeat设置了多行合并,kibana出现日志缺失

xiaoaps 回复了问题 • 5 人关注 • 8 个回复 • 4312 次浏览 • 2019-01-29 10:25 • 来自相关话题

Elasticsearch查询问题

laoyang360 回复了问题 • 2 人关注 • 1 个回复 • 2144 次浏览 • 2018-06-14 19:29 • 来自相关话题

elastic search 查询问题

laoyang360 回复了问题 • 2 人关注 • 1 个回复 • 2967 次浏览 • 2018-06-14 19:21 • 来自相关话题

用curator删除定时删除索引,删除后集群不知为何又重建创建了这个索?

chengzi_xs 回复了问题 • 5 人关注 • 4 个回复 • 8160 次浏览 • 2019-09-17 17:48 • 来自相关话题

elasticsearch更新,排序

kennywu76 回复了问题 • 3 人关注 • 1 个回复 • 1961 次浏览 • 2018-06-14 16:17 • 来自相关话题

elaseticsearch update all能实现么

strglee 回复了问题 • 2 人关注 • 1 个回复 • 3365 次浏览 • 2018-06-14 11:40 • 来自相关话题

ES5.3聚合内存溢出bug

yayg2008 发表了文章 • 1 个评论 • 5160 次浏览 • 2018-06-13 20:48 • 来自相关话题

有以下DSL
json<br /> {<br /> "size" : 0,<br /> "query" : { },<br /> "_source" : false,<br /> "aggregations" : {<br /> "aggData" : {<br /> "terms" : {<br /> "field" : "url",<br /> "size" : 200,<br /> "min_doc_count" : 1,<br /> "shard_min_doc_count" : 0,<br /> "show_term_doc_count_error" : false,<br /> "order" : [<br /> {<br /> "PV" : "desc"<br /> }<br /> ]<br /> },<br /> "aggregations" : {<br /> "PV" : {<br /> "cardinality" : {<br /> "field" : "userssid"<br /> }<br /> }<br /> }<br /> }<br /> }<br /> }<br />
目的是对用户访问的URL进行分组统计,按独立用户数来排序。
执行后,data节点频繁FGC,内存无法回收,随即OOM,然后data节点脱离,集群变为red。
最初以为是cardinality精度问题导致内存使用过多,随即将precision_threshold设置为100,再次执行,内存使用量确实少了很多,但是还是用到GB级别。为了确认是否是cardinality问题,去掉外层聚合,直接执行
json<br /> "aggregations" : {<br /> "PV" : {<br /> "cardinality" : {<br /> "field" : "userssid"<br /> }<br /> }<br /> }<br />
发现响应非常快,而且内存占用只有KB级别。
再次单独执行外部聚合,发现也非常快,于是猜测是order导致,将order去掉,果然,如丝般顺滑,再也没有OOM。
为了解决这种OOM,首先想到的是熔断器。默认indices.breaker.request.limit配置是60%。改成10%后,触发熔断,集群正常,但是多点几次之后,data还是出现OOM了。
于是逐步调试,发现每执行1次,内存就增加一点,熔断返回后并没有被回收,直到OOM。基本确定是这里的order导致内存泄露了。
就在此时,同事反馈在5.6不会有这个问题,于是去查release note,果然在[5.5的版本](https://www.elastic.co/guide/e ... 0.html)发现fix了这个问题。[问题描述](https://github.com/elastic/elasticsearch/pull/24941)。
这个bug的根本原因是:
<br /> terms aggregations at the root level use the global_ordinals execution hint by default.<br /> When all sub-aggregators can be run in breadth_first mode the collected buckets for these sub-aggs are dense (remapped after the initial pruning).<br /> But if a sub-aggregator is not deferrable and needs to collect all buckets before pruning we don't remap global ords and the aggregator needs to deal with sparse buckets.<br /> Most (if not all) aggregators expect dense buckets and uses this information to allocate memories.<br /> This change forces the remap of the global ordinals but only when there is at least one sub-aggregator that cannot be deferred.<br />
解决方案:
1,升级到5.5以上版本;

2,DSL增加"execution_hint":"map",属性。
```json
{
"size" : 0,
"query" : { },
"_source" : false,
"aggregations" : {
"aggData" : {
"terms" : {
"field" : "url",
"size" : 200,
"execution_hint":"map",
"min_doc_count" : 1,
"shard_min_doc_count" : 0,
"show_term_doc_count_error" : false,
"order" : [
{
"PV" : "desc"
}
]
},
"aggregations" : {
"PV" : {
"cardinality" : {
"field" : "userssid"
}
}
}
}
}
}

ELK采集不同项目的日志,会不会存在日志打印到别的系统而获取不到的情况

strglee 回复了问题 • 2 人关注 • 1 个回复 • 2439 次浏览 • 2018-06-13 18:55 • 来自相关话题

esrally测了几次,还是插入索引操作error rate总是100%

回复

john123 发起了问题 • 0 人关注 • 0 个回复 • 3893 次浏览 • 2018-06-13 15:26 • 来自相关话题

按天创建索引问题

531651225@qq.com 回复了问题 • 5 人关注 • 3 个回复 • 7326 次浏览 • 2018-06-13 14:40 • 来自相关话题

spring-data-elasticsearch 如何让es自动生成_id

回复

redhat 发起了问题 • 1 人关注 • 0 个回复 • 4500 次浏览 • 2018-06-13 10:15 • 来自相关话题