Difference between revisions of "UBC secondary parameters"

From OpenVZ Virtuozzo Containers Wiki
Jump to: navigation, search
(formatting fixes)
(more params added (still work in progress))
Line 86: Line 86:
 
by the hardware resources of the system.
 
by the hardware resources of the system.
 
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].
 
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].
 +
 +
== othersockbuf ==
 +
The total size of buffers used by local (UNIX-domain) connections between
 +
processes inside the system (such as connections to a local database server)
 +
and send buffers of UDP and other datagram protocols.
 +
 +
<code>Othersockbuf</code> parameter depends on number of non-TCP sockets (<code>[[numothersock]]</code>).
 +
 +
<code>Othersockbuf</code> configuration should satisfy
 +
 +
<math>othersockbuf_{lim} - othersockbuf_{bar} \ge 2.5KB \cdot numothersock</math>
 +
 +
Increased limit for <code>othersockbuf</code> is necessary for high performance of
 +
communications through local (UNIX-domain) sockets.
 +
However, similarly to <code>tcpsndbuf</code>, hitting <code>othersockbuf</code> affects
 +
the communication performance only and does not affect the functionality.
 +
 +
<code>Othersockbuf</code> limits can't be set arbitrarily high.
 +
The total amount of <code>othersockbuf</code> consumable by all Virtual Environments
 +
in the system plus the <code>kmemsize</code> and other socket buffers
 +
is limited by the hardware resources of the system.
 +
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].
 +
 +
== dgramrcvbuf ==
 +
The total size of buffers used to temporary store the incoming packets of UDP and
 +
other datagram protocols.
 +
 +
<code>Dgramrcvbuf</code> parameters depend on number of
 +
non-TCP sockets (<code>[[numothersock]]</code>).
 +
 +
<code>Dgramrcvbuf</code> limits usually don't need to be high.
 +
Only if the Virtual Environments needs to send and receive very large
 +
datagrams, the <code>barrier</code>s for both <code>othersockbuf</code> and
 +
<code>dgramrcvbuf</code> parameters should be raised.
 +
 +
Hitting <code>dgramrcvbuf</code> means that some datagrams are dropped, which may
 +
or may not be important for application functionality.
 +
UDP is a protocol with not guaranteed delivery, so even if the buffers
 +
permit, the datagrams may be as well dropped later on any stage of the
 +
processing, and applications should be prepared for it.
 +
 +
Unlike other socket buffer parameters, for <code>dgramrcvbuf</code>
 +
the <code>barrier</code> should be set to the <code>limit</code>.
 +
 +
<code>Dgramrcvbuf</code> limits can't be set arbitrarily high.
 +
The total amount of <code>dgramrcvbuf</code> consumable by all Virtual Environments
 +
in the system plus the <code>kmemsize</code> and other socket buffers
 +
is limited by the hardware resources of the system.
 +
This total limit is discussed in [[UBC systemwide configuration#“Low memory”|“low memory”]].
 +
 +
== oomguarpages ==
 +
FIXME
 +
 +
== privvmpages ==
 +
FIXME

Revision as of 13:56, 22 August 2006

User Beancounters
Definition
/proc/user_beancounters
/proc/bc/
General information
Units of measurement
VSwap
Parameters description
Primary parameters
numproc, numtcpsock, numothersock, vmguarpages
Secondary parameters
kmemsize, tcpsndbuf, tcprcvbuf, othersockbuf, dgramrcvbuf, oomguarpages, privvmpages
Auxiliary parameters
lockedpages, shmpages, physpages, numfile, numflock, numpty, numsiginfo, dcachesize, numiptent, swappages
Internals
User pages accounting
RSS fractions accounting
On-demand accounting
UBC consistency
Consistency formulae
System-wide configuration
vzubc(8)
Configuration examples
Basic
Derived
Intermediate configurations
Tables
List of parameters
Parameter properties
Consistency
Config examples

Secondary (dependant) UBC parameters are directly connected to the primary ones and can't be configured arbitrarily.

kmemsize

Size of unswappable memory, allocated by the operating system kernel.

It includes all the kernel internal data structures associated with the Virtual Environment's processes, except the network buffers discussed below. These data structures reside in the first gigabyte of the computer's RAM, so called “low memory”.

This parameter is related to the number of processes (numproc). Each process consumes certain amount of kernel memory — 24 kilobytes at minimum, 30–60 KB typically. Very large processes may consume much more than that.

It is important to have a certain safety gap between the barrier and the limit of the kmemsize parameter (for example, 10%, as in UBC examples). Equal barrier and limit of the kmemsize parameter may lead to the situation where the kernel will need to kill Virtual Environment's applications to keep the kmemsize usage under the limit.

Kmemsize limits can't be set arbitrarily high. The total amount of kmemsize consumable by all Virtual Environments in the system plus the socket buffer space (see below) is limited by the hardware resources of the system. This total limit is discussed in “low memory”.

tcpsndbuf

The total size of buffers used to send data over TCP network connections. These socket buffers reside in “low memory”.

Tcpsndbuf parameter depends on number of TCP sockets (numtcpsock) and should allow for some minimal amount of socket buffer memory for each socket, as discussed in UBC consistency check:

If this restriction is not satisfied, some network connections may silently stall, being unable to transmit data.

Setting high values for tcpsndbuf parameter may, but doesn't necessarily, increase performance of network communications. Note that, unlike most other parameters, hitting tcpsndbuf limits and failed socket buffer allocations do not have strong negative effect on the applications, but just reduce performance of network communications.

Tcpsndbuf limits can't be set arbitrarily high. The total amount of tcpsndbuf consumable by all Virtual Environments in the system plus the kmemsize and other socket buffers is limited by the hardware resources of the system. This total limit is discussed in “low memory”.

tcprcvbuf

The total size of buffers used to temporary store the data coming from TCP network connections. These socket buffers also reside in “low memory”.

Tcprcvbuf parameter depends on number of TCP sockets (numtcpsock) and should allow for some minimal amount of socket buffer memory for each socket, as discussed in UBC consistency check:

If this restriction is not satisfied, some network connections may stall, being unable to receive data, and will be terminated after a couple of minutes.

Similarly to tcpsndbuf, setting high values for tcprcvbuf parameter may, but doesn't necessarily, increase performance of network communications. Hitting tcprcvbuf limits and failed socket buffer allocations do not have strong negative effect on the applications, but just reduce performance of network communications. However, staying above the barrier of tcprcvbuf parameter for a long time is less harmless than for tcpsndbuf. Long periods of exceeding the barrier may cause termination of some connections.

Tcprcvbuf limits can't be set arbitrarily high. The total amount of tcprcvbuf consumable by all Virtual Environments in the system plus the kmemsize and other socket buffers is limited by the hardware resources of the system. This total limit is discussed in “low memory”.

othersockbuf

The total size of buffers used by local (UNIX-domain) connections between processes inside the system (such as connections to a local database server) and send buffers of UDP and other datagram protocols.

Othersockbuf parameter depends on number of non-TCP sockets (numothersock).

Othersockbuf configuration should satisfy

Increased limit for othersockbuf is necessary for high performance of communications through local (UNIX-domain) sockets. However, similarly to tcpsndbuf, hitting othersockbuf affects the communication performance only and does not affect the functionality.

Othersockbuf limits can't be set arbitrarily high. The total amount of othersockbuf consumable by all Virtual Environments in the system plus the kmemsize and other socket buffers is limited by the hardware resources of the system. This total limit is discussed in “low memory”.

dgramrcvbuf

The total size of buffers used to temporary store the incoming packets of UDP and other datagram protocols.

Dgramrcvbuf parameters depend on number of non-TCP sockets (numothersock).

Dgramrcvbuf limits usually don't need to be high. Only if the Virtual Environments needs to send and receive very large datagrams, the barriers for both othersockbuf and dgramrcvbuf parameters should be raised.

Hitting dgramrcvbuf means that some datagrams are dropped, which may or may not be important for application functionality. UDP is a protocol with not guaranteed delivery, so even if the buffers permit, the datagrams may be as well dropped later on any stage of the processing, and applications should be prepared for it.

Unlike other socket buffer parameters, for dgramrcvbuf the barrier should be set to the limit.

Dgramrcvbuf limits can't be set arbitrarily high. The total amount of dgramrcvbuf consumable by all Virtual Environments in the system plus the kmemsize and other socket buffers is limited by the hardware resources of the system. This total limit is discussed in “low memory”.

oomguarpages

FIXME

privvmpages

FIXME