Difference between revisions of "UBC auxiliary parameters"
(created (needs more work)) |
(filled in →lockedpages) |
||
Line 51: | Line 51: | ||
== lockedpages == | == lockedpages == | ||
− | + | Process pages not allowed to be swapped out (pages locked by <code>mlock(2)</code>). | |
+ | |||
+ | 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 Virtual Environments. | ||
+ | Its configuration affects functionality and resource shortage reaction | ||
+ | of applications in the given Virtual Environment only. | ||
== shmpages == | == shmpages == |
Revision as of 14:05, 22 August 2006
Configuration of primary and secondary resource control parameters is important for security and stability of the whole system. Auxiliary parameters differ much from primary and secondary parameters in this respect.
The primary functions of auxiliary parameters are the following.
- These parameters improve application's handling of errors and resource consumption limitations. Without these auxiliary parameters, possible bugs in applications (such as forgetting to unlock locked files or forgetting to collect signals) will cause slowdown and, after some time, killing of the applications because of memory exhaustion. In presence of these parameters, applications will notice the problem (because, for example, attempts to create new file locks start to fail) and show an appropriate message helping to debug the problem. Another example. Each object such as opened file or established network connection consume certain resources. When the Virtual Environment 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 memory allocation or terminate (in case of complete exhaustion of the resources) an already running application.
- These parameters improve fault isolation between applications in the same Virtual Environment. Failures or misbehavior of one application inside a Virtual Environment is more likely to cause hitting a limit on some auxiliary parameter and normal termination of this mis- behaving application, rather than abnormal termination of some other long-running application inside the same Virtual Environment.
- These parameters may be used to impose some administrative limits on the Virtual Environment (for example, to not allow the user to run database servers by limiting the amount of shmpages, or limiting the number of simultaneous shell sessions through numpty).
So, auxiliary parameters play a role similar to limits imposed by
setrlimit(2)
interface and limits configurable by
sysctl(8)
in standard
Linux installations.
Because of this helper role in resource control, system management software may show auxiliary parameters only in advanced mode for experienced administrators and hide them in “basic” management modes.
lockedpages
Process pages not allowed to be swapped out (pages locked by mlock(2)
).
The size of these pages is also accounted into kmemsize
.
The barrier
may be set equal to the limit
or may allow
some gap between the barrier
and the limit
, 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 Virtual Environments. Its configuration affects functionality and resource shortage reaction of applications in the given Virtual Environment only.
shmpages
FIXME
FIXME BIG TIME