Bug#793372: systemd breaks LXC cgroup memory limitations

Carlos Alberto Lopez Perez clopez at igalia.com
Fri Jul 24 01:44:56 BST 2015


Just CC'ing the Debian LXC maintainer and the upstream LXC mailing lists.

I guess they may find relevant this bug.

https://bugs.debian.org/793372

Regards.

On 23/07/15 13:57, Pablo Abelenda wrote:
> Package: systemd
> Version: 215-17+deb8u1
> Severity: important
> 
> Dear Maintainer,
> 
> I have been checking on LXC for a while. I wanted to acquaint with the
> containers management, specifically with the resources limitation
> capabilities.
> 
> I have created, configured and destroyed several containers. The issue
> comes when I try to limit the memory usage. I have added this option to
> the grub defaults:
> 
> cgroup_enable=memory
> 
> This allowed me to start a container with options configured such as
> this:
> 
> lxc.cgroup.memory.limit_in_bytes = 1024M
> lxc.cgroup.memory.memsw.limit_in_bytes = 1200M
> 
> The thing is that when I try to use more than 1200 MB of memory, inside
> the container, I actually can. I have used a very simply script I found
> on someone page to test the memory allocation capabilities.
> 
> ########################################
> memory_allocation.py
> ########################################
> #!/usr/bin/env python
> import sys
> import time
> 
> if len(sys.argv) != 2:
>     print "usage: fillmem <number-of-megabytes>"
>     sys.exit()
> 
> count = int(sys.argv[1])
> 
> megabyte = (0,) * (1024 * 1024 / 8)
> 
> data = megabyte * count
> 
> while True:
>     time.sleep(1)
> ########################################
> 
> I have tried to isolate the problem, focusing on some missing LXC or
> cgroups configuration. Let me add the trace:
> 
> First, I have created a new control group, outside the LXC stuff:
> 
> cgcreate -g memory:/bmalloc1gb
> echo $(( 1024 * 1024 * 1024 ))|tee /sys/fs/cgroup/memory/bmalloc1gb/memory.limit_in_bytes
> echo $(( 1200 * 1024 * 1024 ))|tee /sys/fs/cgroup/memory/bmalloc1gb/memory.memsw.limit_in_bytes
> cgexec -g memory:/bmalloc1gb bash
> python memory_allocation.py 2000 [killed]
> 
> When I run the script on this environment, the memory allocation did not
> went far from this 1200 MB, which is what I need.
> 
> Second, I have joined the LXC cgroup, to try the very same as above:
> 
> cgexec -g memory:lxc/test bash
> python memory_allocation.py 2000 [killed]
> 
> This two tests made me point to LXC, but after some internet digging I
> found this:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777601
> 
> In this bug report, which is not exactly the same as this one, the
> reporter states this:
> 
> "I also tested something which may be another problem (so another ticket)
> but the memory and swap limitation doesn't work at all :-(...with or
> without this bug. I can't tell if it's linked or not.
> I tested cpu pinning and it works like a charm. The issue seems related
> to memory and swap only."
> 
> After this income information, I have switched back both the host and
> the container, to sysvinit. With the systems booted on sysvinit, the
> memory limitation is working as it is expected.
> 
> Let me add the whole container configuration for your reference:
> 
> lxc.cgroup.cpuset.cpus = 0,1
> lxc.cgroup.cpu.shares = 256
> lxc.cgroup.blkio.weight = 500
> lxc.cgroup.memory.limit_in_bytes = 1024M
> lxc.cgroup.memory.memsw.limit_in_bytes = 1200M
> lxc.network.type = veth
> lxc.network.flags = up
> lxc.network.link = br0
> lxc.network.name = eth0
> lxc.rootfs = /dev/vg/test
> lxc.start.auto = 1
> lxc.include = /usr/share/lxc/config/debian.common.conf
> lxc.mount = /var/lib/lxc/test/fstab
> lxc.utsname = test
> lxc.arch = amd64
> lxc.autodev = 1
> 
> Thanks for your consideration.
> 
> Best regards.
> 
> 
> -- Package-specific info:
> 
> -- System Information:
> Debian Release: 8.1
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages systemd depends on:
> ii  acl             2.2.52-2
> ii  adduser         3.113+nmu3
> ii  initscripts     2.88dsf-59
> ii  libacl1         2.2.52-2
> ii  libaudit1       1:2.4-1+b1
> ii  libblkid1       2.25.2-6
> ii  libc6           2.19-18
> ii  libcap2         1:2.24-8
> ii  libcap2-bin     1:2.24-8
> ii  libcryptsetup4  2:1.6.6-5
> ii  libgcrypt20     1.6.3-2
> ii  libkmod2        18-3
> ii  liblzma5        5.1.1alpha+20120614-2+b3
> ii  libpam0g        1.1.8-3.1
> ii  libselinux1     2.3-2
> ii  libsystemd0     215-17+deb8u1
> ii  mount           2.25.2-6
> ii  sysv-rc         2.88dsf-59
> ii  udev            215-17+deb8u1
> ii  util-linux      2.25.2-6
> 
> Versions of packages systemd recommends:
> ii  dbus            1.8.18-0+deb8u1
> ii  libpam-systemd  215-17+deb8u1
> 
> Versions of packages systemd suggests:
> pn  systemd-ui  <none>
> 
> -- no debconf information
> 
> 
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 883 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20150724/1dd9537f/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list