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