You may set any value from 100 up to 800 Mb for the first one andThis use case works well for providing guarantee to one container.If I set up 9 groups to have 100Mb limit then I have 100Mb assured (onE.g. I have a node with 1Gb of ram and 10 containers with 100MbDon't start the new container or change the guarantees of the existing
guarantee each.
I want to start one more. What shall I do not to break guarantees?
ones
to accommodate this one :) The QoS design (done by the administrator)
should
take care of such use-cases. It would be perfectly ok to have a
container
that does not care about guarantees to set their guarantee to 0 and set
their limit to the desired value. As Chandra has been stating we
need two
parameters (guarantee, limit), either can be optional, but not both.
1Gb node)
for the 10th one exactly. And I do not have to set up any guarantee as
it won't affect
anything. So what a guarantee parameter is needed for?
What if
I want guarantees of 100Mb and 200Mb for two containers? How do I setup
the system using limits?
200-900Mb for
the second. In case of no other groups first will receive its 100Mb for
sure and
so does the second. If there are other groups - their guarantees should
be concerned.
Even I restrict everyone else to 700Mb. With this I cannot be sure thatThere's no "everyone else" here - we're talking about a "static" case.
the remaining 300Mb will be distributed as 100Mb and 200Mb.
When new group arrives we need to recalculate guarantees as you said.
And here's my next question - what to do if the new guarantee would become
lower that current amount of unreclaimable memory in BC?