[mesos] branch master updated: Logged headroom related info in the allocator.

[mz...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

mzhu pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mesos.git


The following commit(s) were added to refs/heads/master by this push:
     new 6bbf183  Logged headroom related info in the allocator.
6bbf183 is described below

commit 6bbf18319892df35c68a9b4f745adf6aa5b727c3
Author: Meng Zhu <mz...@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 708c444..83b90d5 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;
+
   // We randomize the agents here to "spread out" the effect of the first
   // stage, which tends to allocate from the front of the agent list more
   // so than the back.
@@ -2078,6 +2094,8 @@ void HierarchicalAllocatorProcess::__allocate()
 
         if (!sufficientHeadroom) {
           toAllocate -= headroomResources;
+          heldBackForHeadroom += headroomToAllocate;
+          ++heldBackAgentCount;
         }
 
         // If the framework filters these resources, ignore.
@@ -2107,6 +2125,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 {