Difference between revisions of "UBC secondary parameters"
(created (needs more work)) |
(No difference)
|
Revision as of 13:13, 22 August 2006
|
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:
Failed to parse (unknown function "\cr"): {\displaystyle tcpsndbuf_{lim} - tcpsndbuf_{bar} \ge 2.5KB \cdot numtcpsock \rm.\cr}}
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:
Failed to parse (unknown function "\cr"): {\displaystyle tcprcvbuf_{lim} - tcprcvbuf_{bar} \ge 2.5KB \cdot numtcpsock \rm.\cr} }
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 [UBC systemwide configuration#“Low memory”|“low memory”]].