[SPARK-49386][CORE][SQL][FOLLOWUP] More accurate memory tracking for memory based spill threshold #52190
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
cloud-fan
commented
Sep 1, 2025
| private val inMemoryThreshold = conf.windowExecBufferInMemoryThreshold | ||
| private val spillThreshold = conf.windowExecBufferSpillThreshold | ||
| private val spillSizeThreshold = conf.windowExecBufferSpillSizeThreshold | ||
| private val sizeInBytesSpillThreshold = conf.windowExecBufferSpillSizeThreshold |
Contributor
Author
There was a problem hiding this comment.
For now I reuse the spill threshold config for the ExternalAppendOnlyUnsafeRowArray in-memory buffer threshold as well. We can add new configs if we want (but it will be a lot of configs).
cloud-fan
commented
Sep 2, 2025
core/src/main/java/org/apache/spark/shuffle/sort/ShuffleExternalSorter.java
Show resolved
Hide resolved
cloud-fan
commented
Sep 2, 2025
core/src/main/java/org/apache/spark/shuffle/sort/ShuffleExternalSorter.java
Outdated
Show resolved
Hide resolved
cxzl25
reviewed
Sep 3, 2025
| if (numRows < numRowsInMemoryBufferThreshold) { | ||
| // Once spills, we will switch to UnsafeExternalSorter permanently. | ||
| if (spillableArray == null && numRows < numRowsInMemoryBufferThreshold && | ||
| inMemoryBufferSizeInBytes < sizeInBytesSpillThreshold) { |
Contributor
There was a problem hiding this comment.
Should sizeInBytesInMemoryBufferThreshold be used ?
Contributor
Author
There was a problem hiding this comment.
oh I made a typo here...
| * of using an [[ArrayBuffer]] or [[Array]]. | ||
| */ | ||
| private[sql] class ExternalAppendOnlyUnsafeRowArray( | ||
| class ExternalAppendOnlyUnsafeRowArray( |
Contributor
There was a problem hiding this comment.
Does private[sql] need to be removed?
The previous PR added parameters in ExternalAppendOnlyUnsafeRowArray, but the documentation for ExternalAppendOnlyUnsafeRowArray was not updated.
Contributor
Author
There was a problem hiding this comment.
other data structures (ShuffleExternalSorter, UnsafeExternalSorter, etc.) are all public classes under a private package. I just make them consistent here, not a big deal and I'm fine to revert as well.
Contributor
Author
There was a problem hiding this comment.
I've updated the classdoc
cloud-fan
commented
Sep 3, 2025
sql/core/src/main/scala/org/apache/spark/sql/execution/ExternalAppendOnlyUnsafeRowArray.scala
Outdated
Show resolved
Hide resolved
cloud-fan
commented
Sep 3, 2025
sql/core/src/main/scala/org/apache/spark/sql/execution/ExternalAppendOnlyUnsafeRowArray.scala
Outdated
Show resolved
Hide resolved
…lAppendOnlyUnsafeRowArray.scala
Ngone51
approved these changes
Sep 4, 2025
Member
|
Merged to master, thanks! |
huangxiaopingRD
pushed a commit
to huangxiaopingRD/spark
that referenced
this pull request
Nov 25, 2025
…memory based spill threshold ### What changes were proposed in this pull request? This is a followup of apache#47856 . It makes the memory tracking more accurate in several places: 1. In `ShuffleExternalSorter`/`UnsafeExternalSorter`, the memory is used by both the sorter itself, and its underlying in-memort sorter (for sorting shuffle partition ids). We need to add them up to calcuate the current memory usage. 2. In `ExternalAppendOnlyUnsafeRowArray`, the records are inserted to an in-memory buffer first. If the buffer gets too large (currently based on num records), we switch to `UnsafeExternalSorter`. The in-memory buffer also needs a memory based threshold ### Why are the changes needed? More accurate memory tracking results to better spill decisions ### Does this PR introduce _any_ user-facing change? No, the feature is not released yet. ### How was this patch tested? existing tests ### Was this patch authored or co-authored using generative AI tooling? no Closes apache#52190 from cloud-fan/spill. Lead-authored-by: Wenchen Fan <[email protected]> Co-authored-by: Wenchen Fan <[email protected]> Signed-off-by: Yi Wu <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes were proposed in this pull request?
This is a followup of #47856 . It makes the memory tracking more accurate in several places:
ShuffleExternalSorter/UnsafeExternalSorter, the memory is used by both the sorter itself, and its underlying in-memort sorter (for sorting shuffle partition ids). We need to add them up to calcuate the current memory usage.ExternalAppendOnlyUnsafeRowArray, the records are inserted to an in-memory buffer first. If the buffer gets too large (currently based on num records), we switch toUnsafeExternalSorter. The in-memory buffer also needs a memory based thresholdWhy are the changes needed?
More accurate memory tracking results to better spill decisions
Does this PR introduce any user-facing change?
No, the feature is not released yet.
How was this patch tested?
existing tests
Was this patch authored or co-authored using generative AI tooling?
no