Ryu Kobayashi created YARN-11907:
------------------------------------
Summary: FairSharePolicy: compareDemand() causes queue starvation
for empty queues with pending apps
Key: YARN-11907
URL: https://issues.apache.org/jira/browse/YARN-11907
Project: Hadoop YARN
Issue Type: Bug
Components: fairscheduler
Reporter: Ryu Kobayashi
h3. Problem
FairSharePolicy.compareDemand() assigns lowest priority to queues with
demand=0, preventing progression to Stage 2 (minShare comparison). This causes
severe queue starvation when a queue becomes empty but has applications waiting
for
ApplicationMaster allocation.
h3. Reproduction Scenario
A leaf queue with the following characteristics experiences starvation:
* Queue becomes temporarily empty (all previous jobs complete)
* New applications are submitted and enter ACCEPTED state
* Queue has demand=0 (no running containers) but getNumRunnableApps() > 0
(apps waiting for AM)
* Other queues continue receiving AM allocations
* The empty queue receives no AM allocations for extended periods (hours)
Observed behavior:
* Queue remains starved for 2+ hours
* Multiple applications wait 100+ minutes for AM allocation
* Cluster has available resources during this period
* Other queues receive thousands of container allocations
h3. Root Cause{*}{*}
[FairSharePolicy.java|https://github.com/apache/hadoop/blob/rel/release-3.4.2/hadoop-yarn-project/hadoop-yarn/hadoop-yarn-server/hadoop-yarn-server-resourcemanager/src/main/java/org/apache/hadoop/yarn/server/resourcemanager/scheduler/fair/policies/FairSharePolicy.java#L119-L131]
Lines 119-131:
{code:java}
private int compareDemand(Schedulable s1, Schedulable s2) {
int res = 0;
long demand1 = s1.getDemand().getMemorySize();
long demand2 = s2.getDemand().getMemorySize();
if ((demand1 == 0) && (demand2 > 0)) {
res = 1; // Queue with demand=0 receives lowest priority
} else if ((demand2 == 0) && (demand1 > 0)) {
res = -1;
}
return res;
} {code}
When a queue has no running containers (demand=0) but has applications in
ACCEPTED state waiting for AM allocation, the queue is assigned lowest priority
in Stage 1 comparison and never progresses to Stage 2 (minShare comparison),
making
minResources configuration ineffective.
h3. Why Configuration Cannot Solve This
Setting minResources in fair-scheduler.xml does not prevent this starvation due
to two issues:
1. Stage 1 blocks Stage 2: compareDemand() returns non-zero for empty queues,
preventing progression to compareMinShareUsage()
2. MinShare calculation caps at demand: Even if reaching Stage 2, lines 136-141
cap minShare:
long minShare1 = Math.min(s1.getMinShare().getMemorySize(),
s1.getDemand().getMemorySize()); // When demand=0, minShare becomes 0
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
