Repository navigation
MSQ: Consider PARTITION_STATS_MAX_BYTES in WorkerMemoryParameters. - #13274
Conversation
This consideration is important, because otherwise we can run out of memory due to large statistics-tracking objects.
cryptoe
left a comment
There was a problem hiding this comment.
Minor comment. LGTM otherwise.
|
|
||
| // Need to subtract memoryForStatisticsTracking off the top, since this is reserved for statistics collection. | ||
| final long memoryForStatisticsTracking = (long) numWorkersInJvm * StageDefinition.PARTITION_STATS_MAX_BYTES; | ||
| final long memoryForBundles = (long) (maxMemoryInJvm * USABLE_MEMORY_FRACTION - memoryForStatisticsTracking); |
There was a problem hiding this comment.
Should we add a > 0 check here? That way the user knows that he needs to give more memory to the task
There was a problem hiding this comment.
There's a reasonable error that occurs later on; see WorkerMemoryParametersTest.
| void finish() | ||
| { | ||
| if (resultKeyStatisticsCollector != null) { | ||
| resultKeyStatisticsCollector.clear(); |
| ) | ||
| { | ||
| final long usableMemory = (long) (maxMemoryInJvm * USABLE_MEMORY_FRACTION); | ||
| final long memoryForWorkers = (long) Math.min( |
There was a problem hiding this comment.
Nice. This is really cool and will go a long way in fixing the memory issues of sketches.
|
We might have to update this line |
|
Pushed an update fixing merge conflicts, updating |
|
🚀 |
…pache#13274) * MSQ: Consider PARTITION_STATS_MAX_BYTES in WorkerMemoryParameters. This consideration is important, because otherwise we can run out of memory due to large statistics-tracking objects. * Improved calculations.
This consideration is important, because otherwise we can run out of memory due to large statistics-tracking objects.