Memory inside Linux containers

http://fabiokung.com/2014/03/13/memory-inside-linux-containers/#

by craigkerstiens • 12 years ago

77 8 12 years ago

cbhl• 12 years ago

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

fabiokung• 12 years ago

It's possible, but only part of a possible solution. Those tools still would need a (standard) place to read cgroup specific data from inside the container.

fat0wl• 12 years ago

Further, /sys/fs/cgroup is just an umbrella for all cgroup hierarchies, there is no recommendation or standard for my own cgroup location.

I think the key is just this bit & wanting to develop standards in the Linux container community.

WestCoastJustin2• 12 years ago

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...

wmf• 12 years ago

It's not clear that CoreOS helps since it does not provide the userspace that runs inside the container. It looks like most people are building Docker images based on Ubuntu or busybox.

WestCoastJustin2• 12 years ago

Yeah, you are totally right! I did not think that through enough. It is all dependent upon the tools inside the container. Should be interesting to see how this one plays out.

falconfunction• 12 years ago

So aliases don't work?

georgebarnett• 12 years ago

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.

Memory inside Linux containers

Related Stories