This is an automated email from the ASF dual-hosted git repository.
mzhu pushed a commit to branch 1.6.x
in repository https://gitbox.apache.org/repos/asf/mesos.git
commit 4111b84060b1576317fae362c811567d596b719c
Author: Meng Zhu <m...@mesosphere.io>
AuthorDate: Mon Apr 29 17:49:15 2019 -0700
Logged headroom related info in the allocator.
This patch logs `requiredHeadroom` and `availableHeadroom`
before each allocation cycle and logs `requiredHeadroom`,
resources and number of agents held back for quota `headroom`
as well as resources filtered at the end of each allocation
cycle.
While we also held resources back for quota headroom in the
first stage, we do not log it there. This is because in the
second stage, we try to allocate all resources (including the
ones held back in the first stage). Thus only resources held
back in the second stage are truly held back for the whole
allocation cycle.
Review: https://reviews.apache.org/r/70570
---
src/master/allocator/mesos/hierarchical.cpp | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/src/master/allocator/mesos/hierarchical.cpp
b/src/master/allocator/mesos/hierarchical.cpp
index c9d97dc..1c11a3f 100644
--- a/src/master/allocator/mesos/hierarchical.cpp
+++ b/src/master/allocator/mesos/hierarchical.cpp
@@ -1734,6 +1734,10 @@ void HierarchicalAllocatorProcess::__allocate()
slave.getAvailable().revocable().createStrippedScalarQuantity();
}
+ LOG(INFO) << "Before allocation, required quota headroom is "
+ << requiredHeadroom
+ << " and available quota headroom is " << availableHeadroom;
+
// Due to the two stages in the allocation algorithm and the nature of
// shared resources being re-offerable even if already allocated, the
// same shared resources can appear in two (and not more due to the
@@ -2009,6 +2013,18 @@ void HierarchicalAllocatorProcess::__allocate()
// are not part of the headroom (and therefore can't be used to satisfy
// quota guarantees).
+ // For logging purposes, we track the number of agents that had resources
+ // held back for quota headroom, as well as how many resources in total
+ // were held back.
+ //
+ // While we also held resources back for quota headroom in the first stage,
+ // we do not track it there. This is because in the second stage, we try to
+ // allocate all resources (including the ones held back in the first stage).
+ // Thus only resources held back in the second stage are truly held back for
+ // the whole allocation cycle.
+ Resources heldBackForHeadroom;
+ size_t heldBackAgentCount = 0;
+
foreach (const SlaveID& slaveId, slaveIds) {
foreach (const string& role, roleSorter->sort()) {
// In the second allocation stage, we only allocate
@@ -2118,6 +2134,8 @@ void HierarchicalAllocatorProcess::__allocate()
if (!sufficientHeadroom) {
toAllocate -= headroomToAllocate;
+ heldBackForHeadroom += headroomToAllocate;
+ ++heldBackAgentCount;
}
// If the resources are not allocatable, ignore. We cannot break
@@ -2154,6 +2172,12 @@ void HierarchicalAllocatorProcess::__allocate()
}
}
+ LOG(INFO) << "After allocation, " << requiredHeadroom
+ << " are required for quota headroom, "
+ << heldBackForHeadroom << " were held back from "
+ << heldBackAgentCount
+ << " agents to ensure sufficient quota headroom";
+
if (offerable.empty()) {
VLOG(2) << "No allocations performed";
} else {
