[
https://issues.apache.org/jira/browse/SPARK-60134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126861#comment-18126861
]
L. C. Hsieh commented on SPARK-60134:
-------------------------------------
I prototyped this (track per-consumer granted-but-unreleased bytes in
TaskMemoryManager and drop a consumer when it reaches zero) and am closing this
as Won't Fix, since the benefit does not justify the added complexity:
- Retention is not reduced. The consumers that a task can create many of
register a task completion listener that captures the consumer, so they stay
reachable until the task ends regardless of TaskMemoryManager. Examples:
UnsafeExternalSorter (one per large group in ExternalAppendOnlyUnsafeRowArray
for SMJ/window), ExternalSorter, ExternalAppendOnlyMap,
SegmentTreeWindowFunctionFrame, and UnsafeFixedWidthAggregationMap.
- Tasks have few consumers. Instrumenting core memory/sorter suites plus
JoinSuite (incl. SMJ spill), SQLWindowFunctionSuite, HashedRelationSuite, etc.
showed at most 5 distinct consumers per task, and usually 0-2. The spill loops
and the OOM breakdown already skip consumers with zero usage, so stale entries
only cost a getUsed() read per spill.
- A correct removal needs a second accounting. MemoryConsumer.getUsed() cannot
be used to decide removal, because consumers update it before or after calling
into TaskMemoryManager, and it does not include an in-flight page grant. For
example, a consumer that spills itself during page allocation recovery would be
dropped while it is about to hold the new page. A correct version needs
parallel per-consumer bookkeeping kept in sync with acquiredButNotUsed across
every allocatePageInternal branch, plus a separate lock so that releases do not
block behind a thread waiting in the execution pool. A future bug there would
silently hide a consumer from spilling, which is worse than the stale entries
it removes.
Follow-up of the discussion in
https://github.com/apache/spark/pull/59331#discussion_r4236874042.
> Remove memory consumers from TaskMemoryManager once they no longer hold memory
> ------------------------------------------------------------------------------
>
> Key: SPARK-60134
> URL: https://issues.apache.org/jira/browse/SPARK-60134
> Project: Spark
> Issue Type: Improvement
> Components: Spark Core
> Affects Versions: 4.4.0
> Reporter: L. C. Hsieh
> Priority: Major
>
> TaskMemoryManager adds a consumer to its consumers set on every
> acquireExecutionMemory call, but nothing removes it before
> cleanUpAllAllocatedMemory() at the end of the task. A consumer that has
> released all its memory (or has been closed) therefore stays reachable until
> the task ends, together with everything it references, and both spill loops
> (acquireExecutionMemory and spillConsumersForPageAllocation) keep scanning it
> on every spill.
> This was raised in the review of SPARK-60112
> (https://github.com/apache/spark/pull/59331#discussion_r4236874042). After
> SPARK-60112 tracks consumers by identity, equal-but-distinct consumers that
> used to be collapsed into a single entry are each retained this way, although
> the same already holds for any other distinct consumer.
> Proposal: drop a consumer from the set once it no longer holds memory (for
> example when its usage reaches zero, or when it is closed), instead of only
> ever adding to it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
