Editing UBC systemwide configuration
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
{{UBC toc}} | {{UBC toc}} | ||
− | The [[UBC consistency check]] article discussed validation of | + | The [[UBC consistency check]] article discussed validation of a resource control configuration |
+ | for a single container. This article discusses checks that the configuration of the | ||
'''whole''' system is '''valid'''. | '''whole''' system is '''valid'''. | ||
Line 17: | Line 18: | ||
The best way to make sure that the configuration of the whole system | The best way to make sure that the configuration of the whole system | ||
is valid is to run periodic automatic checks, based on the formulae described | is valid is to run periodic automatic checks, based on the formulae described | ||
− | below | + | below. |
== Resource utilization and commitment level == | == Resource utilization and commitment level == | ||
Line 27: | Line 28: | ||
containers at the given time. | containers at the given time. | ||
In general, low utilization values mean that the system is under-utilized. | In general, low utilization values mean that the system is under-utilized. | ||
− | Often, it means that the system is capable of supporting more | + | Often, it means that the system is capable of supporting more Virtual |
− | if the existing containers continue to maintain | + | Environment if the existing containers continue to maintain |
the same load and resource consumption level. | the same load and resource consumption level. | ||
High utilization values (in general, more than <code>1</code>) | High utilization values (in general, more than <code>1</code>) | ||
Line 42: | Line 43: | ||
overcommitted. | overcommitted. | ||
If the system runs a lot of containers, | If the system runs a lot of containers, | ||
− | it is usually acceptable to have some overcommitment, because it is unlikely that all | + | it is usually acceptable to have some overcommitment, because it is unlikely that all Virtual |
+ | Environments will request resources at the same time. | ||
However, higher commitment levels (as discussed below for each resource | However, higher commitment levels (as discussed below for each resource | ||
individually) will cause containerss to experience failures to | individually) will cause containerss to experience failures to | ||
allocate and use the resources promised to them. | allocate and use the resources promised to them. | ||
− | == “Low memory” ( | + | == “Low memory” (x86 specific) == |
Because of specifics of architecture of Intel's x86 processors, the RAM of the | Because of specifics of architecture of Intel's x86 processors, the RAM of the | ||
computer can't be used uniformly. | computer can't be used uniformly. | ||
Line 196: | Line 198: | ||
The normal commitment level is about <math>0.8</math>—<math>1</math>. | The normal commitment level is about <math>0.8</math>—<math>1</math>. | ||
− | Commitment levels more than <math>1</math> means that the | + | Commitment levels more than <math>1</math> means that the Virtual Environmens are |
guaranteed more memory than the system has. | guaranteed more memory than the system has. | ||
Such overcommitment is strongly not recommended, because in that case | Such overcommitment is strongly not recommended, because in that case | ||
Line 204: | Line 206: | ||
It is better to guarantee containers less and have less commitment | It is better to guarantee containers less and have less commitment | ||
− | levels than to | + | levels than to accidently overcommit the system by memory plus swap. |
If the system has spare memory and swap, containers will | If the system has spare memory and swap, containers will | ||
transparently be able to use the memory and swap above their guarantees. | transparently be able to use the memory and swap above their guarantees. | ||
Line 329: | Line 331: | ||
However, for stability-critical applications, it's better to keep | However, for stability-critical applications, it's better to keep | ||
the level not exceeding <math>1</math>. | the level not exceeding <math>1</math>. | ||
− | |||
− |