[Q] LXC configuration wizard: what is "CPU limit" & "CPU unit"?

Spazmic

New Member
Sep 13, 2015
15
1
3
I feel like downgrading from 3.4 to 4.3. It hurts, I had faith in Proxmox.

Just wanted to add my voice to the unhappy people because of proxmox staff not acknowledging that they made a mistake.
 

Spazmic

New Member
Sep 13, 2015
15
1
3
What mistake to you talk about exactly?
LXC. I understand there are good reasons to go from openvz to lxc, but the fact that the containers can see the node's info is a major drawback that makes proxmox unusable for different kind of production environments.
 

dietmar

Proxmox Staff Member
Staff member
Apr 28, 2005
16,670
359
103
Austria
www.proxmox.com
I understand there are good reasons to go from openvz to lxc, but the fact that the containers can see the node's info is a major drawback that makes proxmox unusable for different kind of production environments.
Yes, there was many reasons. But I agree, every solution has its own features and drawbacks. So I would suggest that you help to improve LXC - we make good progress.
 
  • Like
Reactions: Spazmic

Fixweb

New Member
Mar 10, 2016
5
2
3
Paris
The core limiting is now working on the last version ! This is a very good point for all hosters ;)
 

Philipp Page

Member
Apr 26, 2016
30
0
6
22
Concerning the CPU limit again. It now shows correctly the amount of CPUs in the container in htop but it still shows the CPU load of the hosts core, is it possible to show the containers cpu usage there?
 

Luis Vazquez

New Member
Apr 13, 2020
2
0
1
50
Uruguay
There is no direct relation, because sockets/cores are just attributes describing the processor architecture,
and we simply use the host architecture for containers. CPU limit/units are CFS scheduler settings, which are now available
for containers and kvm VMs.

CPU units is a CFS scheduler feature described here (cpu.shares):

https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt

CPU limit refers to 'cfs_period_us' feature described here:

https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt

So CPU limit is basically the maximum number of cores a container can utilize.
After reading carefully the documentation in the following links:
I have to say it seems the information given by Dietmar above is not 100% right.
  1. It's correct that "CPU Unit" corresponds to cpu.shares (default 1024) and this has to be with the relative priority of the current VM/container with respect to the rest (priority is given by my cpu.share divided among the sum of all the cpu.shares).
  2. It's correct that "CPU limit" has to do with the maximum usage of physical CPU Cores (in running time) a VM or container may get, but this IS NOT the cfs_period_us. Instead it is related to the quotient (cfs_quota_us / cfs_period_us) defined as the parameter "cpulimit" in KVM.
    As explined in the links above "cfs_period_us is the length of a period in microseconds" or the window for the CPU bandwith control an this is usuarlly 100000 o 100ms (not configurable in PVE). On the other side, cfs_quota_us is "the total available run-time within a period" (also in microseconds) or the number of microseconds the VM/container is allowed to use in that window (counting all the CPUs).
    For example if cfs_period_us=100000 and cfs_quote_us=200000, this means the VM/container will be able to get 100% of 2 cpus in each 100ms period, so the quotient will be 2.0 (200%)
In KVM (and in the Proxmox documentation cited above) this value is a floating point representing the real quotient value (1.0=100%, 2.5=250%) but for some reason in the design of the PVE web interface found interesting to change this to the scale 1 to 128, as if you would have a server with 128 cores. I suppose this is to make the value independent of the number of the number of cores in the server, but the concept is the same: 128 represents all the CPU power and values below the corresponding fraction.

As an example, if you have a server with 8 CPU cores, a value of 128 corresponds to cpulimit=8.0=800% or the VM may fully use the 8 CPUs. In this case if you want to limit the VM/container to only a single CPU used at 100%, you have to put this value to 128/8 = 16.
 

Luis Vazquez

New Member
Apr 13, 2020
2
0
1
50
Uruguay
I have made some more testing on this and the meaning of "CPU Units" as the value of cpu.shares is clear and consistent. For a VM with CPU Units = 2048 I have this:

root@pve01:~# cat /sys/fs/cgroup/cpu/qemu.slice/101.scope/cpu.shares
2048


However the meaning of "CPU Limit" setting for the PVE Web interface, seems more inconsistent that I thought and really now I'm suspecting this is not working as expected!
For a value of "CPU Limit" = 64 with a maximum of 128 you would expect this gives half of the server capacity (and this is stated in many Proxmox howto docs and online courses all over the web) ; however in a 8 cpu server these are the corresponding values defined for cfs_period_us and cfs_quota_us:

root@pve01:~# cat /sys/fs/cgroup/cpu/qemu.slice/101.scope/cpu.cfs_period_us
100000
root@pve01:~# cat /sys/fs/cgroup/cpu/qemu.slice/101.scope/cpu.cfs_quota_us
6400000


As seen, cfs_period_us has its default value of 100000=10⁵ microsecs (or 100 ms), but then cfs_quota_us gets 64x10⁵ with is 64 times the full period of cpu time or the time of execution of 64 processors!! Obviously this will never be reached in a 8 cpu system, and then this will not limit anything!

In conclusion, the value in "CPU Limits" correspond to an absolute value of full cpu usage for the VM in a range from 1 to 128, and then all the values above the number of real cpus in the system are useless (from 8 to 128 in my case).

This seems far from intuitive, and in my opinion this value should be a floating point ranging from 1 (or some value below 1) to the total number of CPUs available in the system, and clearly documented as the (may be fractional) number of real CPUs time assigned to the VM (which can't be above the number of available CPUs)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!