UBC primary parameters - Revision history

Kir: simplify toc

2011-10-01T21:04:00Z

simplify toc

Nathanhaigh: /* Units */

2011-08-15T23:12:31Z

‎Units

Nathanhaigh: Indented parameters by another heading level so toc is easier to follow. linked units subheading to the UBC parameter units page

2011-08-15T22:40:32Z

Indented parameters by another heading level so toc is easier to follow. linked units subheading to the UBC parameter units page

Kir: /* vmguarpages */ MAX_ULONG -> LONG_MAX

2011-01-25T13:50:50Z

‎vmguarpages: MAX_ULONG -> LONG_MAX

DmitryKoterov: /* vmguarpages */

2010-11-11T23:33:18Z

‎vmguarpages

DmitryKoterov: /* vmguarpages */

2010-11-11T23:32:36Z

‎vmguarpages

DmitryKoterov: /* vmguarpages */

2010-11-11T23:31:38Z

‎vmguarpages

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

2008-03-11T10:41:19Z

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

Kir: /* numproc */ THE

2007-10-08T09:10:56Z

‎numproc: THE

Kir: /* numothersock */ THE

2007-10-08T09:09:59Z

‎numothersock: THE

@@ Line 6: / Line 6: @@
 server applications.
-== UBC Primary Parameters ==
+== numproc ==
 Maximum number of processes and kernel-level threads allowed for this container.
@@ Line 35: / Line 33: @@
 to 8000 processes in a system.
-=== numtcpsock ===
+== numtcpsock ==
 Maximum number of TCP sockets.
@@ Line 52: / Line 50: @@
 the memory is a limited resource.
-=== numothersock ===
+== numothersock ==
 Maximum number of non-TCP sockets (local sockets, UDP and other types of sockets).
@@ Line 76: / Line 74: @@
 resource.
-=== vmguarpages ===
+== vmguarpages ==
 Memory allocation guarantee.
@@ Line 117: / Line 115: @@
 There is a ''pseudo-graphical'' tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all physical memory blocks graphically in <code>/etc/vz/conf/MEM-MAP</code> text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).

← Older revision		Revision as of 23:12, 15 August 2011
Line 120:		Line 120:

	== Units ==		== Units ==
−	~~For full article, see: [[~~UBC parameter units]]	+	{{Main\|UBC parameter units}}

@@ Line 6: / Line 6: @@
 server applications.
-== numproc ==
+== UBC Primary Parameters ==
 Maximum number of processes and kernel-level threads allowed for this container.
@@ Line 33: / Line 35: @@
 to 8000 processes in a system.
-== numtcpsock ==
+=== numtcpsock ===
 Maximum number of TCP sockets.
@@ Line 50: / Line 52: @@
 the memory is a limited resource.
-== numothersock ==
+=== numothersock ===
 Maximum number of non-TCP sockets (local sockets, UDP and other types of sockets).
@@ Line 74: / Line 76: @@
 resource.
-== vmguarpages ==
+=== vmguarpages ===
 Memory allocation guarantee.
@@ Line 115: / Line 117: @@
 There is a ''pseudo-graphical'' tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all physical memory blocks graphically in <code>/etc/vz/conf/MEM-MAP</code> text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).

@@ Line 91: / Line 91: @@
 (see [[privvmpages]]). The meaning of the <code>limit</code> for the
 <code>vmguarpages</code> parameter is unspecified in the current version and should be set
-to the maximal allowed value ([[MAX_ULONG]]).
+to the maximal allowed value ([[LONG_MAX]]).
 If the current amount of allocated memory space does not exceed the

← Older revision		Revision as of 23:33, 11 November 2010
Line 114:		Line 114:
	and the swap space — as discussed in [[UBC systemwide configuration]].		and the swap space — as discussed in [[UBC systemwide configuration]].

−	There is a tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all physical memory blocks graphically in <code>/etc/vz/conf/MEM-MAP</code> text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).	+	There is a ''pseudo-graphical'' tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all physical memory blocks graphically in <code>/etc/vz/conf/MEM-MAP</code> text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).

← Older revision		Revision as of 23:32, 11 November 2010
Line 114:		Line 114:
	and the swap space — as discussed in [[UBC systemwide configuration]].		and the swap space — as discussed in [[UBC systemwide configuration]].

−	There is a tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all ~~the~~ physical memory blocks graphically in /etc/vz/conf/MEM-MAP text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).	+	There is a tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all physical memory blocks graphically in <code>/etc/vz/conf/MEM-MAP</code> text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).

← Older revision		Revision as of 23:31, 11 November 2010
Line 113:		Line 113:
	are limited by the physical resources of the computer — the size of RAM		are limited by the physical resources of the computer — the size of RAM
	and the swap space — as discussed in [[UBC systemwide configuration]].		and the swap space — as discussed in [[UBC systemwide configuration]].
		+
		+	There is a tool - <code>[http://en.dklab.ru/lib/dklab_vzmem/ vzmem]</code> - which allows you to distribute physical memory among all VEs consistently. It shows all the physical memory blocks graphically in /etc/vz/conf/MEM-MAP text file and lets you to move these blocks from one VE to another to redistribute the memory. Also you may specify "additional" memory personally for each VE: such memory will be obtained from system's free memory or swap (it is reflected as modifying of <code>privvmpages</code> parameter).

@@ Line 2: / Line 2: @@
 The most important parameters determining the resources available to
-Virtual Environment are explained below. The meaning of the parameters
+container are explained below. The meaning of the parameters
-is illustrated assuming that the Virtual Environment runs some network
+is illustrated assuming that the container runs some network
 server applications.
 == numproc ==
-Maximum number of processes and kernel-level threads allowed for this Virtual Environment.
+Maximum number of processes and kernel-level threads allowed for this container.
 Many server applications (like Apache Web server, FTP and mail servers)
@@ Line 42: / Line 42: @@
 The <code>barrier</code> of this parameter should be set equal to the <code>limit</code>.
-If each Virtual Environment has it's own set of IP addresses (which is
+If each container has it's own set of IP addresses (which is
 the only way a OpenVZ system can be configured), there are no direct
 limits on the total number of TCP sockets in the system. The number
@@ Line 83: / Line 83: @@
 more memory it needs.
-The amount of memory that Virtual Environment's applications are
+The amount of memory that container's applications are
 guaranteed to be able to allocate is specified as the <code>barrier</code> of
 <code>vmguarpages</code> parameter. The current amount of allocated memory space
@@ Line 95: / Line 95: @@
 If the current amount of allocated memory space does not exceed the
 guaranteed amount (the <code>barrier</code> of <code>vmguarpages</code>),
-memory allocations of Virtual Environment's applications always succeed.
+memory allocations of container's applications always succeed.
 If the current amount of allocated memory space exceeds the guarantee but below
 the <code>barrier</code> of <code>privvmpages</code>, allocations may or may not succeed,
@@ Line 105: / Line 105: @@
 made by the applications fail.
 The memory allocation guarantee (<code>vmguarpages</code>) is a primary tool for
-controlling the memory available to Virtual Environments, because
+controlling the memory available to containers, because
 it allows administrators to provide Service Level Agreements — agreements
 guaranteeing certain quality of service, certain amount of resources
 and general availability of the service. The unit of measurement
 of vmguarpages values is memory pages (4KB on x86 and x86_64 processors).
-The total memory allocation guarantees given to Virtual Environments
+The total memory allocation guarantees given to containers
 are limited by the physical resources of the computer — the size of RAM
 and the swap space — as discussed in [[UBC systemwide configuration]].

@@ Line 20: / Line 20: @@
 control parameters may depend both on the limit and the average number (see [[UBC consistency check]]).
-<code>Barrier</code> of <code>numproc</code> doesn't provide additional control and should be set equal to the <code>limit</code>.
+The <code>barrier</code> of <code>numproc</code> doesn't provide additional control and should be set equal to the <code>limit</code>.
 There is a restriction on the total number of processes in the system.

@@ Line 64: / Line 64: @@
 (SNMP agents and others).
-<code>Barrier</code> of this parameter should be set equal to the <code>limit</code>.
+The <code>barrier</code> of this parameter should be set equal to the <code>limit</code>.
 The number of local sockets in a system is not limited. The number of
 UDP sockets in a system, similarly to TCP sockets, is not limited in