This is an automated email from the ASF dual-hosted git repository. mzhu pushed a commit to branch 1.8.x in repository https://gitbox.apache.org/repos/asf/mesos.git
commit 6c6f2ffb6c2a59da3d89d5dbd51392b0efdba850 Author: Meng Zhu <[email protected]> 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 64a076d..282af46 100644 --- a/src/master/allocator/mesos/hierarchical.cpp +++ b/src/master/allocator/mesos/hierarchical.cpp @@ -1795,6 +1795,10 @@ void HierarchicalAllocatorProcess::__allocate() slave.getAvailable().revocable().scalars()); } + 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 @@ -2005,6 +2009,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. + ResourceQuantities heldBackForHeadroom; + size_t heldBackAgentCount = 0; + foreach (const SlaveID& slaveId, slaveIds) { CHECK(slaves.contains(slaveId)); Slave& slave = slaves.at(slaveId); @@ -2073,6 +2089,8 @@ void HierarchicalAllocatorProcess::__allocate() if (!sufficientHeadroom) { toAllocate -= headroomResources; + heldBackForHeadroom += headroomToAllocate; + ++heldBackAgentCount; } // If the framework filters these resources, ignore. @@ -2102,6 +2120,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 {
