-
Notifications
You must be signed in to change notification settings - Fork 550
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Quality of Service #114
Comments
On Tue, Aug 25, 2015 at 04:48:58PM -0700, Vish Kannan wrote:
We need to expose the underlying knobs to let the runtime-caller
We can do this with namespaces now 2. Similar handling in
We have disableOOMKiller, which landed without docs in #51. But yeah,
|
As requested during the last meeting, following is the rationale for this feature: Setting resource limits is tricky for containers. More often than not, users end up allocating more resources than what is necessary. To further improve node utilization, users can run batch tasks like map-reduce, which end up using resources that are not used by other category of tasks. Whenever the higher priority tasks need more resources, these batch tasks will be killed. These batch tasks are expected to tolerate failures. A common pattern will be to run latency sensitive user facing applications with preset limits, thereby guaranteeing them resources. cc @philips |
@wking: +1 for not handling relationship between containers. It is not necessary and higher layers can manage that. |
I take back my previous comment. How can we set |
On Mon, Oct 12, 2015 at 12:39:39PM -0700, Vish Kannan wrote:
What is the problem you expect? Everything you need for this should |
The API has to let users express the notion of priority among containers. Consider the case when a web server is run alongside a logging container. The web-server is more important than the logging side-car container. When there is a resource crunch, the user doesn't mind killing one of the lower priority containers, which is logging in this case. Ideally, if all containers were to be run with limits, this might not be necessary. In reality though, setting limits is hard and users tend to over provision resources and that leads to poor resource utilization.
Since this notion of priority can be expressed in different ways, I propose letting users handle cgroup management and only expose the following knobs:
The text was updated successfully, but these errors were encountered: