Not enough capacity for even one row! Need[1,509,995,528] but have[0]

Hello,
Using Druid 0.11, when sending a groupBy query (v2) with a large number of aggregations (>1000) and postAggregations, we are receiving the mentioned error:

Not enough capacity for even one row! Need[1,509,995,528] but have[0]

So the question is, is druid inherently limited to “large” queries, or do we have some misconfiguration?

A sample query is attached, but it contains only a sample of the aggregations and filters.

Our historical configuration contains the following parameters:

druid.processing.buffer.sizeBytes=2147483647

druid.processing.numThreads=31

druid.processing.numMergeBuffers is default and results in 7.

While debugging we noticed that the mergeBuffers are sliced into 31 slices, and these smaller sizes are used in the calculation of the needed capacity.

As we understand it, a slice should be equal or larger than the calculated bucketSizeWithHash (in the ByteBufferHashTable). Because our druid.processing.buffer.sizeBytes is around 2GB each slice is around 70MB, and 70MB is not enough to the requested 1.5GB (Need[1,509,995,528]).

We made some progress by defining druid.processing.numThreads=1 so there is only one slice of 2GB, but then we encountered the following issue: https://github.com/druid-io/druid/issues/5086

Also we are not so sure if this approach of 1 thread is a good idea at all.

Increasing the size of druid.processing.buffer.sizeBytes beyond the ~2GB is impossible, as we encounter a configuration error, because we are crossing the Integer.MAX_VALUE.

So as I’ve asked at the beginning, is it possible to run such queries, or are we limited by design?

Thanks.

Igor.

large-query-sample.txt (5.38 KB)

Hey Igor,

Oh my word. I never thought anyone would want to run with so many sketch aggregators in a single query. Surely, I thought, nobody will ever need more than a few MB of them per row, but here we are with 1.5GB. Anyway - since you don’t have any dimensions in your groupBy, I’d suggest running with queryType “timeseries” as a workaround. The timeseries engine should be able to handle this case.

Out of curiosity what is the reason you need so many sketch aggregators?

Hi Gian,

Thanks a lot for you quick reply. Your suggestion helped, the query now returns results.

The use case for this query is to display a count of unique users with an intersection between two groups of attributes, and also display unique count of users for each of the attributes.

Thanks again.

Igor.