Memory constraints and lxc containers

[Stuart Bishop]

On 27 February 2015 at 18:00, Edward Hope-Morley
<edward.hope-morley at canonical.com> wrote:
> Maybe this can help (thanks to Serge):
>
> The simplest way is to use
>
>         cgm getvalue memory ''  memory.usage_in_bytes

That looks good, thanks. I haven't had success yet, with the cgm tool
in the container unable to talk to something on the host system, but
it looks like a way forward. I imagine cgmanager would need to be a
dependency of juju-core, and machines and containers get the relevant
tools installed by Juju. I could then add the relevant helper to
charm-helpers, allowing charms to choose better default settings.

> as that only requires cgmanager on the host and in the container.
>
> You can also use lxcfs.  You can use it on trusty, but it requires having
> ppa:ubuntu-lxc/daily.  You'd do
>
> sudo add-apt-repository ppa:ubuntu-lxc/daily
> sudo apt-get update
> sudo apt-get install lxcfs
>
> Now lxcfs will run and mount a filesystem under /var/lib/lxcfs.  The lxc
> from that same ppa will (I assume) automatically hook newly created
> containers to use lxcfs.  For any pre-existing containers, you can just
> add
>
> lxc.include = /usr/share/lxc/config/common.conf.d
>
> to /var/lib/lxc/<container/config
>
> That should make it so when you start the container, /proc/meminfo inside
> the container is virtualized.

Even easier. Just use /proc/meminfo and friends, which gives you
'correct' values if the package has been installed in the correct
places and falls back to todays behavior. juju-core would just need to
ensure the package is a dependency and installed on provisioned
machines once it gets out of the PPA.



> On 27/02/15 09:27, Stuart Bishop wrote:
>> Hi.
>>
>> I've seen several bug reports and workarounds for charms that need to
>> tune memory settings, which tends to fail horribly when using the
>> local provider or deploying to lxc containers. It seems to be
>> impossible to infer how much RAM a service should be using. The end
>> result is extra configuration items override inferred values, and
>> non-lxc specific code paths.
>>
>> I'm not sure what the solution should be. Are there suitable container
>> constraints that could be passed to the charm, and charms make their
>> decisions based on the constraints rather than using the global system
>> values and hoping there is only a single container on the system?
>> Should the lxc containers be setup with limited resources and be
>> reporting that, instead of the system values?
>>
>> Memory is the one I've seen tripped over several times. I also lxc
>> specific code paths for disabling swap and messing with sysctl
>> settings, but these are less common and don't cause your system to
>> grind to a halt when you are testing a charm locally and your desktop
>> gets swapped out.
>>
>



-- 
Stuart Bishop <stuart.bishop at canonical.com>