7. Managing Container CPU resources :-
The current section explains the CPU resource parameters that you can configure and monitor for each Container.
The table below provides the name and the description for the CPU parameters. The File column indicates whether the parameter is defined in the OpenVZ global configuration file (G) or in the CT configuration files (V).
parameter Description File
======================================================
A)ve0cpuunits >> determines the minimal guaranteed share of the CPU time Container 0 (the Hardware Node itself) will receive. It is recommended to set the value of this parameter to be 5-10% of the power of the Hardware Node(commadn to show power of node :vzcpucheck). After the Node is up and running, you can redefine the amount of the CPU time allocated to the command : Node by using the --cpuunits parameter with the vzctl set 0 command. >> G
B)cpuunits >> This is a positive integer number that determines the minimal guaranteed share of the CPU time the corresponding Container will receive. >> V
C)cpulimit >> This is a positive number indicating the CPU time in per cent the corresponding CT is not allowed to exceed. >> V
D ) cpus >>The number of CPUs to be used to handle the processes running inside the corresponding Container.
>> V
==========
8. Managing CPU Share : -The OpenVZ CPU resource control utilities allow you to guarantee any Container the amount of CPU time this Container receives. The Container can consume more than the guaranteed value if there are no other Containers competing for the CPU and the cpulimit parameter is not defined.
Note: The CPU time shares and limits are calculated on the basis of a one-second period. Thus, for example, if a Container is not allowed to receive more than 50% of the CPU time, it will be able to receive no more than half a second each second.
To get a view of the optimal share to be assigned to a Container, check the current Hardware Node CPU utilization:
# vzcpucheck =========>>>
Current CPU utilization: 5166
Power of the node: 73072.5
The output of this command displays the total number of the so-called CPU units(ie 5166 seconds) consumed by all running Containers and Hardware Node processes. Power of the node: 429892 , this is the max no of seconds unites of this node can perform.
Besides, CT 102 will not receive more than 4% of the CPU time even if the CPU is not fully loaded:
# vzctl set 102 --cpuunits 1500 --cpulimit 4 --save
Saved parameters for CT 102
# vzctl start 102
Starting CT …
CT is mounted
Adding IP address(es): 192.168.1.102
CT start in progress…
# vzcpucheck
Current CPU utilization: 6667
Power of the node: 73072.5
To set the --cpuunits parameter for the Hardware Node, you should indicate 0 as the Container ID (e.g. vzctl set 0 --cpuunits 5000 --save).
==============================
9. Configuring Number of CPUs Inside Container : -
If your Hardware Node has more than one physical processor installed, you can control the number of CPUs which will be used to handle the processes running inside separate Containers. By default, a Container is allowed to consume the CPU time of all processors on the Hardware Node, i.e. any process inside any Container can be executed on any processor on the Node. However, you can modify the number of physical CPUs which will be simultaneously available to a Container using the --cpus option of the vzctl set command. For example, if your Hardware Node has 4 physical processors installed, i.e. any Container on the Node can make use of these 4 processors, you can set the processes inside Container 101 to be run on 2 CPUs only by issuing the following command:
# vzctl set 101 --cpus 2 --save
Note: The number of CPUs to be set for a Container must not exceed the number of physical CPUs installed on the Hardware Node. In this case the 'physical CPUs' notation designates the number of CPUs the OpenVZ kernel is aware of (you can view this CPU number using the cat /proc/cpuinfo command on the Hardware Node).
=============================
10 : Managing System Parameters :
The resources a Container may allocate are defined by the system resource control parameters. These parameters can be subdivided into the following categories: primary, secondary, and auxiliary parameters. The primary parameters are the start point for creating a Container configuration from scratch. The secondary parameters are dependent on the primary ones and are calculated from them according to a set of constraints. The auxiliary parameters help improve fault isolation among applications in one and the same Container and the way applications handle errors and consume resources. They also help enforce administrative policies on Containers by limiting the resources required by an application and preventing the application to run in the Container.
Listed below are all the system resource control parameters. The parameters starting with «num» are measured in integers. The parameters ending in «buf» or «size» are measured in bytes. The parameters containing «pages» in their names are measured in 4096-byte pages (IA32 architecture). The File column indicates that all the system parameters are defined in the corresponding CT configuration files (V).
==
Primary parameters Parameter Description File
avnumproc >> The average number of processes and threads. V
numproc >> The maximal number of processes and threads the CT may create. V
numtcpsock >> The number of TCP sockets (PF_INET family, SOCK_STREAM type). This parameter limits the number of TCP connections and, thus, the number of clients the server application can handle in parallel. V
numothersock >> The number of sockets other than TCP ones. Local (UNIX-domain) sockets are used for communications inside the system. UDP sockets are used, for example, for Domain Name Service (DNS) queries. UDP and other sockets may also be used in some very specialized applications (SNMP agents and others). V
vmguarpages >> The memory allocation guarantee, in pages (one page is 4 Kb). CT applications are guaranteed to be able to allocate additional memory so long as the amount of memory accounted as privvmpages (see the auxiliary parameters) does not exceed the configured barrier of the vmguarpages parameter. Above the barrier, additional memory allocation is not guaranteed and may fail in case of overall memory shortage. V
------------------------
Secondary parameters Parameter Description File
kmemsize >> The size of unswappable kernel memory allocated for the internal kernel structures for the processes of a particular CT. V
tcpsndbuf >> The total size of send buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data sent from an application to a TCP socket, but not acknowledged by the remote side yet. V
tcprcvbuf >> The total size of receive buffers for TCP sockets, i.e. the amount of kernel memory allocated for the data received from the remote side, but not read by the local application yet. V
othersockbuf >> The total size of UNIX-domain socket buffers, UDP, and other datagram protocol send buffers. V
dgramrcvbuf >> The total size of receive buffers of UDP and other datagram protocols. V
oomguarpages >> The out-of-memory guarantee, in pages (one page is 4 Kb). Any CT process will not be killed even in case of heavy memory shortage if the current memory consumption (including both physical memory and swap) does not reach the oomguarpages barrier. V
---------------------
Auxiliary parameters Parameter Description File
lockedpages >> The memory not allowed to be swapped out (locked with the mlock() system call), in pages. V
shmpages >> The total size of shared memory (including IPC, shared anonymous mappings and tmpfs objects) allocated by the processes of a particular CT, in pages. V
privvmpages >> The size of private (or potentially private) memory allocated by an application. The memory that is always shared among different applications is not included in this resource parameter. V
numfile >>The number of files opened by all CT processes. V
numflock >>The number of file locks created by all CT processes. V
numpty >>The number of pseudo-terminals, such as an ssh session, the screen or xterm applications, etc. V
numsiginfo >> The number of siginfo structures (essentially, this parameter limits the size of the signal delivery queue). V
dcachesize >> The total size of dentry and inode structures locked in the memory. V
physpages >> The total size of RAM used by the CT processes. This is an accounting-only parameter currently. It shows the usage of RAM by the CT. For the memory pages used by several different CTs (mappings of shared libraries, for example), only the corresponding fraction of a page is charged to each CT. The sum of the physpages usage for all CTs corresponds to the total number of pages used in the system by all the accounted users. V
numiptent >> The number of IP packet filtering entries. V
You can edit any of these parameters in the /etc/vz/conf/CTID.conf file of the corresponding Container by means of your favorite text editor (for example, vi or emacs), or by running the vzctl set command. For example:
# vzctl set 101 --kmemsize 2211840:2359296 --save
Saved parameters for CT 101
======================
No comments:
Post a Comment