This is an automated email from the ASF dual-hosted git repository. mzhu pushed a commit to branch 1.7.x in repository https://gitbox.apache.org/repos/asf/mesos.git
commit 6a41b9b65c220ef742f7ec802c6ba90bea522808 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 514887f..53db6ad 100644 --- a/src/master/allocator/mesos/hierarchical.cpp +++ b/src/master/allocator/mesos/hierarchical.cpp @@ -1780,6 +1780,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 @@ -2019,6 +2023,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) { CHECK(slaves.contains(slaveId)); Slave& slave = slaves.at(slaveId); @@ -2086,6 +2102,8 @@ void HierarchicalAllocatorProcess::__allocate() if (!sufficientHeadroom) { toAllocate -= headroomToAllocate; + heldBackForHeadroom += headroomToAllocate; + ++heldBackAgentCount; } if (!allocatable(toAllocate) || @@ -2115,6 +2133,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 {
