Github user paul-rogers commented on a diff in the pull request:
https://github.com/apache/drill/pull/860#discussion_r128134981
--- Diff:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/xsort/managed/SortMemoryManager.java
---
@@ -312,52 +488,66 @@ private void adjustForLowMemory() {
* one spill batch to make progress.
*/
- private void lowMemorySpillBatchSize() {
+ private void lowMemoryInternalBatchSizes() {
// The "expected" size is with power-of-two rounding in some vectors.
// We later work backwards to the row count assuming average internal
// fragmentation.
- // Must hold two input batches. Use (most of) the rest for the spill
batch.
+ // Must hold two input batches. Use half of the rest for the spill
batch.
+ // In a really bad case, the number here may be negative. We'll fix
+ // it below.
- expectedSpillBatchSize = (int) (memoryLimit - 2 * estimatedInputSize);
+ int spillBufferSize = (int) (memoryLimit - 2 *
inputBatchSize.maxBufferSize) / 2;
--- End diff --
Buffer, in the sense of the amount of memory set aside for the spill batch.
We work backwards to get the spill batch size.
Yes, in the worst case, the estimated spill batch size will be negative,
meaning we don't even have room to hold two input batches, let alone any spill
batches.
The negative number is not fixed. Instead, the resulting spill batch row
count is clamped at a minimum of 1 in `rowsPerBatch()`. Also, we whine to the
log file that we've got too little memory and that Bad Things are likely to
happen.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
