How to limit resources on a system container?

[streamnsight]

Testing this out, I was trying to limit the resources on the system container and see the effect inside the system container.

I tried passing the docker run option flags like --cpus=1 on launching the system container, but once inside, I still see 2 CPUs.

Same trying to use -m or --memory: this seems to have no effect.

How I can define/limit the resources for the system container?

[ctalledo]

Hi Emmanuel, thanks trying out Nestybox system containers, your feedback is very much appreciated!

I tried passing the docker run option flags like --cpus=1 on launching the system container, but once inside, I still see 2 CPUs.

When you say you see 2 CPUs, what command are you using to pull this info?

When I pass the --cpus=1 to docker run, I do see the system container has its cpu shares constrained via the cpu cgroup:

$ docker run --runtime=sysbox-runc -it --cpus=1 debian:latest
root@6d8d2e8c433d:/#

From the host, let's see the cpu shares assigned to the system container:

$ cd /sys/fs/cgroup/cpu,cpuacct/docker/6d8d2e8c433dd941e07b9b7108f0638973cbbd34651407e7b36a596f8542924d
$ more cpu.cfs_quota_us
100000
$ more cpu.cfs_period_us
100000

That confirms that the system container cpu shares are constrained.

Contrast this to a system container without any cpu share restriction:

$ docker run --runtime=sysbox-runc -it debian:latest
root@655be46431a9:/#

From the host:

$ cd /sys/fs/cgroup/cpu,cpuacct/docker/655be46431a9b5ca0a7382186aa01bea722fed8df801d4ad9c332056d9e1a3ae
$ more cpu.cfs_quota_us
-1
$ more cpu.cfs_period_us
100000

You can see the difference in the cpu.cfs_quota_us.

Now here is the thing: from within the system container, you can't tell:

$ docker run --runtime=sysbox-runc -it --cpus=1 debian:latest
root@c57ba9b7e4fc:/# cd /sys/fs/cgroup/cpu/
root@c57ba9b7e4fc:/# more cpu.cfs_quota_us
-1 
root@c57ba9b7e4fc:/# more cpu.cfs_period_us
100000

This is by design: one of our goals is for the system container to provide the abstraction of a virtual host. From within the system container a process thinks it has all resources of the virtual host available to it. That's why cpu.cfs_quota_us returns -1. Ideally processes inside the system container are not aware that there is a real host underneath and that the system container has been assigned a subset of its resources.

Having said this, we still have more work to do in order to complete this abstraction. For example, from within the system container, cpu related info under /proc/ should be returned with respect to the cpu resources assigned to the system container. This is not currently the case.

Note that this stands in contrast to a regular application container, which does expose the cpu shares assigned to it by the host. For example, if a launch a regular Docker container with the --cpus option, you see:

$ docker run --runtime=runc -it --rm --cpus=1 debian:latest
root@863106b351b8:/# cd /sys/fs/cgroup/cpu
root@863106b351b8:# more cpu.cfs_quota_us
100000
root@863106b351b8:# more cpu.cfs_period_us
100000

Hope this explains it. If you see any issues with this let us know.

[streamnsight]

When you say you see 2 CPUs, what command are you using to pull this info?

I was looking at the output of /proc/cpuinfo as well as htop to check system memory / cpus

Are you saying this is not quite abstracted yet, but the container is effectively restricted through the cgroups?

[ctalledo]

Are you saying this is not quite abstracted yet, but the container is effectively restricted through the cgroups?

My apologies for the belated response. Yes, exactly.

[ctalledo]

Closing the issue. Thanks for the questions raised.