[
https://issues.apache.org/jira/browse/DRILL-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16093512#comment-16093512
]
ASF GitHub Bot commented on DRILL-5601:
---------------------------------------
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.
> Rollup of External Sort memory management fixes
> -----------------------------------------------
>
> Key: DRILL-5601
> URL: https://issues.apache.org/jira/browse/DRILL-5601
> Project: Apache Drill
> Issue Type: Task
> Affects Versions: 1.11.0
> Reporter: Paul Rogers
> Assignee: Paul Rogers
> Fix For: 1.12.0
>
>
> Rollup of a set of specific JIRA entries that all relate to the very
> difficult problem of managing memory within Drill in order for the external
> sort to stay within a memory budget. In general, the fixes relate to better
> estimating memory used by the three ways that Drill allocates vector memory
> (see DRILL-5522) and to predicting the size of vectors that the sort will
> create, to avoid repeated realloc-copy cycles (see DRILL-5594).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
