Description
This meta issue tracks the effort to extend circuit breaker memory tracking beyond the collect phase of aggregations. There are several existing issues related to this, which do a good job of describing the problem (and are linked below), but we need a place to track the tasks for fixing this. That's what this issue is for.
Plan
Currently (8.4) aggregations create an object per collected bucket, called InternalAggregation. These objects are stored in the QuerySearchResult which is responsible for serializing them from the data nodes back to the coordinator, and also for de-serializing them on coordinator side. Managing these objects is quite tricky, and does not provide good places to inject the circuit breaker logic.
Instead, we want to move to a dense representation, which would create one object per aggregator. These objects would be Releasable, and responsible for tracking both the post-collection data node side memory usage and the reduce time coordinating node memory usage. Obviously this involves a (big) change to the wire format used for QuerySearchResult. Doing this in a backwards compatible way is non trivial.
Tasks
Vague Tasks
Related Issues
Description
This meta issue tracks the effort to extend circuit breaker memory tracking beyond the collect phase of aggregations. There are several existing issues related to this, which do a good job of describing the problem (and are linked below), but we need a place to track the tasks for fixing this. That's what this issue is for.
Plan
Currently (8.4) aggregations create an object per collected bucket, called
InternalAggregation. These objects are stored in theQuerySearchResultwhich is responsible for serializing them from the data nodes back to the coordinator, and also for de-serializing them on coordinator side. Managing these objects is quite tricky, and does not provide good places to inject the circuit breaker logic.Instead, we want to move to a dense representation, which would create one object per aggregator. These objects would be
Releasable, and responsible for tracking both the post-collection data node side memory usage and the reduce time coordinating node memory usage. Obviously this involves a (big) change to the wire format used forQuerySearchResult. Doing this in a backwards compatible way is non trivial.Tasks
BigArraysBigIntArray(Big arrays sliced from nettey buffers (int) #89668)BigLongArray(Big arrays sliced from netty buffers (long) #91641)BigByteArray(Big arrays sliced from netty buffers (byte) #92706)BigObjectArrayBigDoubleArray(Big arrays sliced from netty buffers (double) #90745)BigFloatArrayQuerySearchResult. We can lay the ground work for this without defining too much about the format itselfQuerySearchResult(Expand the lifecycle of the AggregationContext #94023)InternalAggregations to work with, we need a pure ordinals based reduction path.LongKeyedBucketOrds(Long key bucket ords key iterator #95809)BytesKeyedBucketOrdsAggregatorTestCasecoverage of the new reduce logic, some howMockBigArraysinAggregatorTestCaseis correctly catching leaks in the new reduce pathLongKeyedBucketOrdsand friends need to becomeWritable, same as we did withBigArrays(and probably leaning on the buffer backed big arrays)Vague Tasks
MaxRangeCardinalityTermsRelated Issues