Memory inside Linux containers

Stéphane Graber's ([1] one of the LXC maintainers) comment [2] highlights just how complex the issue is because cgroups are process based. You could potentially be in a state where "top, free, etc" has a different resource allocation than the process you are monitoring (from within the container). Although, this is most likely a configuration issue i.e. classify at the container level, rather than within a container.

Personally, I think we need container aware tools baked in from the start, rather then a fork of existing ones. I guess this is where CoreOS [3] come into play. Since CoreOS is a dedicated distribution geared towards containers. I guess the idea being, that CoreOS will be fast moving, and add support for this type of thing before the mainstream distribution can (ubuntu, rhel, etc).

btw, if you do not know how cgroups work, check out my screencast on them [4].

[1] https://linuxcontainers.org/

[2] http://fabiokung.com/2014/03/13/memory-inside-linux-containe...

[3] https://coreos.com/

[4] http://sysadmincasts.com/episodes/14-introduction-to-linux-c...

What is infeasible about providing a fork of the userspace tools (free, top, atop, etc.) that reads from the right cgroup filesystem instead?

This issue (and many other resource measurement issues) are solved in OpenVZ but not yet in lxc. In supplying the user a whole virtual image, they are able to shortcut many of the things that don't make sense if you are only sand boxing a single process.

If you are managing a single process then you shouldn't expect to be able to sideline anything in successfully. If you do want to do that, then the single process model isn't the one you ought to use.

I think it's reasonable for lxc to say that an exiting model doesn't fit but it feels very wasteful to throw away a whole raft of user land stuff.

So aliases don't work?