Latest revision |
Your text |
Line 1: |
Line 1: |
− | {{UBC toc}}
| |
− |
| |
| Configuration of primary and secondary resource control parameters is | | Configuration of primary and secondary resource control parameters is |
| important for security and stability of the whole system. Auxiliary | | important for security and stability of the whole system. Auxiliary |
Line 19: |
Line 17: |
| | | |
| Another example. Each object such as opened file or established network | | Another example. Each object such as opened file or established network |
− | connection consume certain resources. When the container | + | connection consume certain resources. When the Virtual Environment |
| is close to exhaustion of the resources allowed to him, it is | | is close to exhaustion of the resources allowed to him, it is |
| usually better to refuse creation of new object than to allow it but deny | | usually better to refuse creation of new object than to allow it but deny |
Line 28: |
Line 26: |
| <li> | | <li> |
| These parameters improve fault isolation between applications in the | | These parameters improve fault isolation between applications in the |
− | same container. Failures or misbehavior of one application | + | same Virtual Environment. Failures or misbehavior of one application |
− | inside a container is more likely to cause hitting a | + | inside a Virtual Environment is more likely to cause hitting a |
| limit on some auxiliary parameter and normal termination of this mis- | | limit on some auxiliary parameter and normal termination of this mis- |
| behaving application, rather than abnormal termination of some other | | behaving application, rather than abnormal termination of some other |
− | long-running application inside the same container. | + | long-running application inside the same Virtual Environment. |
| </li> | | </li> |
| | | |
| <li> | | <li> |
| These parameters may be used to impose some administrative limits | | These parameters may be used to impose some administrative limits |
− | on the container (for example, to not allow the user to run | + | on the Virtual Environment (for example, to not allow the user to run |
| database servers by limiting the amount of [[shmpages]], or limiting the | | database servers by limiting the amount of [[shmpages]], or limiting the |
| number of simultaneous shell sessions through [[numpty]]). | | number of simultaneous shell sessions through [[numpty]]). |
Line 53: |
Line 51: |
| | | |
| == lockedpages == | | == lockedpages == |
− | Process pages not allowed to be swapped out (pages locked by <code>mlock(2)</code>).
| + | FIXME |
− | | |
− | The size of these pages is also accounted into <code>[[kmemsize]]</code>.
| |
− | The <code>barrier</code> may be set equal to the <code>limit</code> or may allow
| |
− | some gap between the <code>barrier</code> and the <code>limit</code>, depending
| |
− | on the nature of applications using memory locking features.
| |
− | | |
− | Note that typical server applications like Web, FTP, mail servers
| |
− | do not use memory locking features.
| |
− | | |
− | The configuration of this parameter doesn't affect security and
| |
− | stability of the whole system or isolation between containers.
| |
− | Its configuration affects functionality and resource shortage reaction
| |
− | of applications in the given container only.
| |
| | | |
| == shmpages == | | == shmpages == |
− | The total size of shared memory (IPC, shared anonymous mappings and
| + | FIXME |
− | <code>tmpfs</code> objects).
| |
− | | |
− | These pages are also accounted into <code>[[privvmpages]]</code>.
| |
− | | |
− | The <code>barrier</code> should be set equal to the <code>limit</code>.
| |
− | The configuration of this parameter doesn't affect security and
| |
− | stability of the whole system or isolation between containers.
| |
− | Its configuration affects functionality and resource shortage reaction
| |
− | of applications in the given container only.
| |
− | | |
− | == physpages ==
| |
− | Total number of RAM pages used by processes in a container.
| |
− | | |
− | For memory pages used by several different containers (mappings of
| |
− | shared libraries, for example), only a fraction of a page is charged to each
| |
− | container.
| |
− | The sum of the <code>physpages</code> usage for all containers
| |
− | corresponds to the total number of pages used in the system by all
| |
− | containers.
| |
− | | |
− | For [[VSwap]]-enabled kernels, the <code>barrier</code> should be set to 0,
| |
− | and the <code>limit</code> limits the total size of RAM used by a container.
| |
− | | |
− | For older kernels, <code>physpages</code> is an accounting-only parameter.
| |
− | The <code>barrier</code> should be set to <code>0</code> and the
| |
− | <code>limit</code> to 'unlimited' ([[LONG_MAX]]).
| |
− | | |
− | == numfile ==
| |
− | Number of open files.
| |
− | | |
− | The <code>barrier</code> should be set equal to the <code>limit</code>.
| |
− | The configuration of this parameter doesn't affect security and
| |
− | stability of the whole system or isolation between containers.
| |
− | Its configuration affects functionality and resource shortage reaction
| |
− | of applications in the given container only.
| |
− | | |
− | Note: actually currently adjusting the <code>barrier</code> will change the kernel behaviour on "pre-charging" the numfile resource. If you change one you will most likely not notice any changes in container behaviour at all. This ability was added for researching purposes purely.
| |
− | | |
− | == numflock ==
| |
− | Number of file locks.
| |
− | | |
− | The configuration of this parameter should have a
| |
− | gap between the <code>barrier</code> and the <code>limit</code>, as illustrated in
| |
− | [[UBC configuration examples]].
| |
− | | |
− | Very high limits on <code>numflock</code> parameters and the big number
| |
− | of file locks in the system may cause certain slowdown of
| |
− | the whole system (but not fatal).
| |
− | So, the limits on this parameter should be reasonable, depending
| |
− | on the real requirements of the applications.
| |
− | | |
− | == numpty ==
| |
− | Number of pseudo-terminals.
| |
− | | |
− | This parameter is usually used to limit the number of simultaneous shell
| |
− | sessions.
| |
− | The <code>barrier</code> should be set equal to the <code>limit</code>.
| |
− | The configuration of this parameter doesn't affect security and
| |
− | stability of the whole system or isolation between containers.
| |
− | Its configuration affects functionality and resource shortage reaction
| |
− | of applications in the given container only.
| |
− | However, in OpenVZ systems, the actual number of pseudo-terminals allowed
| |
− | for one container is limited to <code>256</code>.
| |
− | | |
− | == numsiginfo ==
| |
− | Number of <code>siginfo</code> structures.
| |
− | | |
− | The size of the structure is also accounted into <code>[[kmemsize]]</code>.
| |
− | The default installations of stand-alone Linux systems limit this number
| |
− | to <code>1024</code> for the whole system.
| |
− | In OpenVZ installations, <code>numsiginfo</code> limit applies to each
| |
− | container individually.
| |
− | | |
− | The <code>barrier</code> should be set equal to the <code>limit</code>.
| |
− | Very high settings of the <code>limit</code> of this parameter may reduce
| |
− | responsiveness of the system.
| |
− | It is unlikely that any container will need the limit greater than
| |
− | the Linux default — <code>1024</code>.
| |
− | | |
− | == dcachesize ==
| |
− | The total size of <code>dentry</code> and <code>inode</code> structures locked in memory.
| |
− | | |
− | <code>Dcachesize</code> parameter controls filesystem-related caches, such as
| |
− | directory entry (<code>dentry</code>) and inode caches.
| |
− | The value accounted into <code>dcachesize</code> is also included into
| |
− | <code>[[kmemsize]]</code>.
| |
− | | |
− | <code>Dcachesize</code> exists as a separate parameter to impose a limit causing
| |
− | file operations to sense memory shortage and return an error to applications,
| |
− | protecting from memory shortages during critical operations that shouldn't
| |
− | fail.
| |
− | | |
− | The configuration of this parameter should have a
| |
− | gap between the <code>barrier</code> and the <code>limit</code>, as illustrated in
| |
− | [[UBC configuration examples]].
| |
− | The configuration of this parameter doesn't affect security and
| |
− | stability of the whole system or isolation between containers.
| |
− | Its configuration affects functionality and resource shortage reaction
| |
− | of applications in the given container only.
| |
− | | |
− | == numiptent ==
| |
− | The number of NETFILTER (IP packet filtering) entries.
| |
− | | |
− | The <code>barrier</code> should be set equal to the <code>limit</code>.
| |
− | There is a restriction on the total number of <code>numiptent</code>.
| |
− | It depends on the amount of other allocations in so called “vmalloc”
| |
− | memory area and constitutes about <code>250000</code> entries.
| |
− | Violation of this restriction may cause failures of operations with
| |
− | IP packet filter tables (execution of <code>iptables(8)</code>)
| |
− | in any container or the host system,
| |
− | or failures of container starts.
| |
− | | |
− | Also, large <code>numiptent</code> cause considerable slowdown of processing
| |
− | of network packets. It is not recommended to allow containers
| |
− | to create more than 200–300 <code>numiptent</code>.
| |
− | | |
− | == swappages ==
| |
− | | |
− | The amount of swap space to show in container.
| |
− | | |
− | {{Note|this parameter is only available in RHEL5-based kernel since version 028stab060.2, in 2.6.27 since kiprensky.}}
| |
− | | |
− | The configuration of this parameter doesn't affect security and
| |
− | stability of the whole system or isolation between containers.
| |
− | Its configuration only affects the way OpenVZ kernel reports about
| |
− | available swap in a container. This is needed for some applications
| |
− | which refuse to run inside a container unless the kernel
| |
− | report that no less than some specific amount of swap is available.
| |
− | | |
− | If <code>limit</code> is set, its value is reported as the amount
| |
− | of total swap space in a container.
| |
− | | |
− | If the <code>limit</code> is set to [[LONG_MAX]] (which is the
| |
− | in-kernel default for this parameter), all the swap space values
| |
− | parameters (total, used, free) are reported as 0.
| |
− | | |
− | The value of <code>barrier</code> for this beancounter is ignored.
| |
| | | |
− | The value of <code>held</code> shows how much swap space
| + | FIXME BIG TIME |
− | is currently being used for this container.
| |