UBC systemwide configuration - Revision history

Kir: link to vzmemcheck

2011-06-06T12:11:36Z

link to vzmemcheck

Poige: Made "x86" mention clearer

2009-07-27T05:34:51Z

Made "x86" mention clearer

Kir: VE -> container

2009-04-30T09:08:44Z

VE -> container

Kir: added

2009-04-30T09:01:04Z

added <references/>

Kir: this is about UBC configuration

2008-05-30T11:45:09Z

this is about UBC configuration

Grin: backlink to ubc

2008-05-30T06:48:43Z

backlink to ubc

Kir: VE -> containers

2008-03-11T11:39:18Z

VE -> containers

Botinki Kira: Robot: Automated text replacement (-Virtual Environment +container)

2008-03-11T10:41:39Z

Robot: Automated text replacement (-Virtual Environment +container)

Show changes

Botinki Kira: Robot: Automated text replacement (-VEs +containers)

2008-03-11T09:50:17Z

Robot: Automated text replacement (-VEs +containers)

Kir: /* “Low memory” (x86 specific) */ used->using, other fixes

2008-01-15T20:02:33Z

‎“Low memory” (x86 specific): used->using, other fixes

@@ Line 17: / Line 17: @@
 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
-below.
+below. {{Man|vzmemcheck|8}} utility can be helpful in calculations.
 == Resource utilization and commitment level ==

@@ Line 47: / Line 47: @@
 allocate and use the resources promised to them.
-== “Low memory” (x86 specific) ==
+== “Low memory” (x86_32 specific) ==
 Because of specifics of architecture of Intel's x86 processors, the RAM of the
 computer can't be used uniformly.

@@ Line 27: / Line 27: @@
 containers at the given time.
 In general, low utilization values mean that the system is under-utilized.
-Often, it means that the system is capable of supporting more Virtual
+Often, it means that the system is capable of supporting more containers
-Environment if the existing containers continue to maintain
+if the existing containers continue to maintain
 the same load and resource consumption level.
 High utilization values (in general, more than <code>1</code>)
@@ Line 42: / Line 42: @@
 overcommitted.
 If the system runs a lot of containers,
-it is usually acceptable to have some overcommitment, because it is unlikely that all Virtual
+it is usually acceptable to have some overcommitment, because it is unlikely that all containers will request resources at the same time.
 However, higher commitment levels (as discussed below for each resource
 individually) will cause containerss to experience failures to
@@ Line 197: / Line 196: @@
 The normal commitment level is about <math>0.8</math>—<math>1</math>.
-Commitment levels more than <math>1</math> means that the Virtual Environmens are
+Commitment levels more than <math>1</math> means that the containers are
 guaranteed more memory than the system has.
 Such overcommitment is strongly not recommended, because in that case
@@ Line 205: / Line 204: @@
 It is better to guarantee containers less and have less commitment
-levels than to accidently overcommit the system by memory plus swap.
+levels than to accidentally overcommit the system by memory plus swap.
 If the system has spare memory and swap, containers will
 transparently be able to use the memory and swap above their guarantees.

← Older revision		Revision as of 09:01, 30 April 2009
Line 330:		Line 330:
	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>.
		+
		+	<references/>

@@ Line 1: / Line 1: @@
 {{UBC toc}}
-The [[UBC consistency check]] article discussed validation of a [[resource management|resource control]] configuration for a single container. This article discusses checks that the configuration of the
+The [[UBC consistency check]] article discussed validation of [[UBC]] configuration for a single container. This article discusses checks that the UBC configuration of the
 '''whole''' system is '''valid'''.

@@ Line 63: / Line 63: @@
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (kmemsize_{cur}+allsocketbuf_{cur})}
      {0.4\cdot\min(RAM\ size, {\rm 832MB})}\rm,
@@ Line 83: / Line 83: @@
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (kmemsize_{lim}+allsocketbuf_{lim})}
      {0.4\cdot\min(RAM\ size, {\rm 832MB})}\rm.
@@ Line 112: / Line 112: @@
 <math>
-\sum_{all\ VE}
+\sum_{all\ containers}
      (physpages_{cur}\cdot4096+kmemsize_{cur}+allsocketbuf_{cur})\rm.
 </math>
@@ Line 124: / Line 124: @@
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (physpages_{cur}\cdot4096+
           kmemsize_{cur}+allsocketbuf_{cur})}
@@ Line 172: / Line 172: @@
 === Utilization ===
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (oomguarpages_{cur}\cdot4096+
           kmemsize_{cur}+allsocketbuf_{cur})}
@@ Line 190: / Line 190: @@
 === Commitment level ===
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (oomguarpages_{bar}\cdot4096+
           kmemsize_{lim}+allsocketbuf_{lim})}
@@ Line 236: / Line 236: @@
 === Utilization ===
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (privvmpages_{cur}\cdot4096+
           kmemsize_{cur}+allsocketbuf_{cur})}
@@ Line 261: / Line 261: @@
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (vmguarpages_{bar}\cdot4096+
           kmemsize_{lim}+allsocketbuf_{lim})}
@@ Line 305: / Line 305: @@
 <math>
-\frac{\displaystyle\sum_{all\ VE}
+\frac{\displaystyle\sum_{all\ containers}
          (privvmpages_{lim}\cdot4096+
           kmemsize_{lim}+allsocketbuf_{lim})}

@@ Line 29: / Line 29: @@
 In general, low utilization values mean that the system is under-utilized.
 Often, it means that the system is capable of supporting more Virtual
-Environment if the existing VEs continue to maintain
+Environment if the existing containers continue to maintain
 the same load and resource consumption level.
 High utilization values (in general, more than <code>1</code>)
@@ Line 92: / Line 92: @@
 Virtual Environments.
 Systems with more Virtual Environments may have the commitment level
-increased, to about <math>1.5</math>—<math>2</math> for 400 VEs.
+increased, to about <math>1.5</math>—<math>2</math> for 400 containers.
 Higher commitment levels for this resource are not recommended,
 because the consequences of exceeding the low memory capacities
@@ Line 210: / Line 210: @@
 transparently be able to use the memory and swap above their guarantees.
 Guarantees given to Virtual Environments should not be big, and it is normal
-if memory and swap usage for some VEs stays above their
+if memory and swap usage for some containers stays above their
 guarantee.
 It is also normal to give guarantees only to Virtual Environments with

@@ Line 57: / Line 57: @@
 (or, if the computer has less RAM than 832MB, the size of the RAM).
--bit kernels (i.e x86_64, ia64 and others) can access all memory directly and are not used "low memory" area.
+Note that 64-bit kernels (i.e. x86_64, ia64 etc.) can access all memory
 === Utilization ===
 The lower bound estimation of low memory utilization is