Understanding CPU containers
mukgbv at gmail.com
Wed Sep 9 03:30:27 PDT 2009
I am trying to understand the behavior of CPU containers as I
am unable to explain few things.
- Built the latest kernel 188.8.131.52 and installed on my Intel core2Duo desktop
- Mounted the cpu subsystem using
- mount -t cgroup -ocpu cgroup /containers/cpu/
- Created 3 sub directories under /containers/cpu
- 512 for cpu.shares=512
- 1024 for cpu.shares=1024
- 2048 for cpu.shares=2048
- Created 3 bash terminals and attached each one to the individual cpu
sub system using the /bin/echo command. This essentially allows any
process created by the shells to be automatically added to the cpu
subsystem to which the shell belongs
- Ran a compute intensive benchmark “openssl speed aes-256-cbc”
benchmark on all the shells at the same time.
- Enclosing the numbers from the run…
- Observed CPU Utilization : 99.8 , 49.9 , 49.9
Results from the run
The 'numbers' are in 1000s of bytes per second processed.
CPU shares allocation
16 bytes 64 bytes
256 bytes 1024 bytes 8192 bytes
512 35459.95k 43441.75k
46660.35k 46707.71k 77040.30k
1024 57448.63k 44050.54k
46558.98k 46633.03k 47252.76k
2048 71186.36k 87142.02k
92513.79k 93769.05k 94795.09k
1024 vs 512 1.62 1.01
0.99 0.99 0.61
2048 vs 1024 1.23 1.97
1.98 2.01 2
- Unless the cpu resources are overcommitted, there is no
value in the allocating shares to the containers.
- 2048 vs 1024 cpu containers, the scale is 2X, except for 16 bytes
- 512 vs 1024 cpu containers, there is no difference at all,
except for 16 bytes
- 512 vs 1024 cpu containers, there is no difference for 8192
bytes as the remaining 2 openssl runs are complete.
- For CPU bound, there has to be an over commit on the CPUs
otherwise the share allocation does not matter
- One cannot dynamically assign cpus to the container, by
default, it runs on the no of cores available.
Any pointers are helpful
More information about the Containers