All resource management parameters can be subdivided into the CPU, disk, system, and VSwap categories for your convenience. Any parameter can be set with the prlctl set command and the corresponding option name (in the lower case, e.g., --cpuunits for CPUUNITS, etc.). See Chapter 3, Managing Containers for more details. The Typical value column, if present, specifies a range of reasonable parameter values for different applications, from light to huge heavy loaded containers. If the barrier and limit fields are in use, ranges for both thresholds are given.
Table 2.6. CPU Parameters
| Parameter | Description | Typical value |
|---|---|---|
| CPU weight. This is a positive integer number that defines how much CPU time the container can get as compared to the other virtual machines and containers running on the server. The larger the number, the more CPU time the container can receive. Possible values range from 8 to 500000. If this parameter is not set, the default value of 1000 is used. |
|
| CPU limit, in per cent ( |
|
| Number of CPU cores defining the CPU limit for a container. The limit is calculated by multiplying the power of one CPU core by the number of the specified CPU cores. This option also defines the number of CPUs shown to users from inside a container. This parameter is not set for newly created containers; so they can consume all free CPU power of the server. |
|
| The CPU affinity mask defining which CPUs on the Node can be used to handle the processes running in the container. The CPU mask can be specified as both separate CPU index numbers (1,2,3) and CPU ranges (2-4,5-7). |
|
| The NUMA node mask defining a NUMA node to bind the container to. Once you set the mask, the processes running in the container will be executed only on the CPUs that belong to the specified NUMA node. |
|
Table 2.7. Disk Parameters
| Parameter | Description | Typical value |
|---|---|---|
| Total size of disk space that can be consumed by the container, in 1 KB blocks. | |
| This parameter enables (if set to a value other than |
|
| The container priority for disk I/O operations. The higher the priority, the more time the container has for writing to and reading from the disk. The default container priority is 4. |
|
| The maximum number of disk input and output operations per second a container is allowed to perform. By default, any newly created container does not have the IOPS limit set and can perform so many disk I/O operations per second as necessary. |
|
| The bandwidth a container is allowed to use for its disk input and output (I/O) operations. By default, the limit is set in megabytes per second. However, you can use the following suffixes to use other measurement units:
In the current version of OpenVZ, the maximum I/O bandwidth limit you can set for a container is 2 GB per second. The default I/O bandwidth limit for all newly created containers is set to 0, which means that no limits are applied to any containers. |
|
Table 2.8. System Parameters
| Parameter | Description | Typical value |
|---|---|---|
| Number of processes and threads allowed. Upon hitting this limit, container will not be able to start a new process or thread. |
|
| Number of processes expected to run in the container on average. This is informational parameter used to ensure configuration correctness. |
|
| Memory allocation guarantee, in pages. Applications are guaranteed to be able to allocate memory while the amount of memory accounted as |
|
| Memory not allowed to be swapped out (locked with the |
|
| Total size of shared memory (including IPC, shared anonymous mappings and |
|
| Size of private (or potentially private) memory, allocated by an application. Memory that is always shared among different applications is not included in this resource parameter. | |
| Number of files opened by all container processes. |
|
| Number of file locks created by all container processes. |
|
| Number of pseudo-terminals. For example, the |
|
| Number of |
|
| Total size of RAM used by processes. This parameter is used for accounting purposes only. It shows the usage of RAM by the 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 |
|
| The number of IP packet filtering entries. |
|
Table 2.9. VSwap Parameters
| Parameter | Description | Typical value |
|---|---|---|
| Amount of RAM that can be used by the processes of a container, in 4KB pages. |
|
| Amount of swap space that can be used by the container for swapping out memory once the RAM is exceeded, in 4KB pages. |
|
| Memory overcommit factor that defines the memory allocation limit for a container. The limit is calculated as |
|
