[Q] LXC configuration wizard: what is "CPU limit" & "CPU unit"?
- Thread starter cmonty14
- Start date
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.
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.
Jip, works! Now the kernel messages needs to disappear
Hi,
what kernel messages are you receiving?
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?
After reading carefully the documentation in the following links:
- https://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt
- https://www.kernel.org/doc/Documentation/scheduler/sched-bwc.txt
- https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_cpu
- 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).
- 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%)
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.
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)
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)