This repository was archived by the owner on Sep 10, 2025. It is now read-only.
add support for BinPackFirstFitWeight #8
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
With BinPackFirstFitWeight > 0, it will make diego-cells with a lower BOSH instance index number more attractive to deploy LRPs to. Diego-cells will be filled up more instead spreading the containers accross all diego-cells equally. * Why? Currently we have 64GB memory diego-cells. We need to have the possibility for our customers to deploy 16G containers at all times. This means that we need to have at least 1 diego-cell with 16G memory available at all times. Previously on average 25% (16/64) of the memory on all diego-cells was not used, because every time an LRP is scheduled for deployment, it picks the diego-cell with most memory/disk/pids available. With this change the BOSH instance index number adds some weight to the scheduling algorithm, which will push containers to diego-cells with a lower instance index number when the resources (memory, disk, pids) are available.
|
We have created an issue in Pivotal Tracker to manage this: https://www.pivotaltracker.com/story/show/171108014 The labels on this github issue will be updated when the story is started. |
This was referenced Feb 5, 2020
mariash
reviewed
Feb 20, 2020
| BBSClientSessionCacheSize: 100, | ||
| BBSMaxIdleConnsPerHost: 10, | ||
| CACertFile: "/path-to-cert", | ||
| BinPackFirstFitWeight: 0.0, |
Member
There was a problem hiding this comment.
test a non-zero value to validate that it is passing it through and not using the default Go value for float64.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is part of multiple PRs across rep, auctioneer and auction to add an optional weighted bin pack first fit component to the scheduling algorithm of Cloud Foundry Diego for scheduling LRPs.
PRs/issues involved:
What is this change about?
These PRs combined introduce a new setting for auctioneer:
When
bin_pack_first_fit_weightis set to a value > 0, it will make diego-cells with a lower BOSH instance index number more attractive to deploy LRPs to by adding "weight x diego-cell index" to the score of a diego-cell. Diego-cells will be filled up more instead spreading the LRPs across all diego-cells equally.Setting
bin_pack_first_fit_weightto 0.0 (the default) will effectively disable the optional weighted bin pack first fit component. Everything still keeps working as it was previously.What problem it is trying to solve?
With the current deployment algorithm in diego it spreads the LRPs across all diego-cell instances equally. At Mendix we have 64GB memory diego-cells. We need to have the possibility for our customers to deploy 16G containers at all times. This means that we need to have at least 1 diego-cell with 16G memory available at all times. When the LRPs are spread equally you end up with a situation where on average 25% (16/64) of the memory on all our diego-cells is not used.
What is the impact if the change is not made?
In our case 25% of our diego-cell resources are wasted. We have been running a diego-release with these changes on top for the past months in our production Cloud Foundry foundations. We are saving ten-thousands of $$ monthly on AWS EC2 costs.
How should this change be described in diego-release release notes?
auctioneer
Please provide any contextual information.
Blog post with more information: https://cloud-infra.engineer/saving-costs-with-a-new-scheduler-in-cloud-foundry-diego/
Tag your pair, your PM, and/or team!
I'm not sure who to tag.