Shared memory (shmmax & shmall) odd numbers

LXC
1

The background is that I’m running video capture operations in an LXC container and have behaviour reminiscent of memory limitation issues. The host system is Debian Jessie with its packaged 1.0.6 LXC. I have plenty of memory on the host and sensible (I think) shared memory settings:

         # free 
         total       used       free     shared    buffers     cached
         Mem:      24701384    7938664   16762720     188480    2737872     608968

         # sysctl -a | grep -E "shmall|shmmax"
         kernel.shmall = 655360
         kernel.shmmax = 2500000000

I was aware that I might have issues setting the container up to use this, but what I found when I interrogated it was this:

         # sysctl -a | grep -E "shmall|shmmax"
         kernel.shmall = 18446744073692774399
         kernel.shmmax = 18446744073692774399

Now, by my reckoning that’s more than the physical memory actually in the host system. There are not shmall/shmmax settings in the container’s sysctl.conf.

So, what’s going on? Does the container actually have pretty much unlimited shared memory access within the constraints of the host system’s physical RAM, are those numbers bogus (in which case what should I be looking at) or am I mis-reading something? How do I find out what the effective values for shmall and shmmax in the container actually are?

The system in question is mission critical and delicate in many ways so I’d rather stick to Jessie and the stock Debian packages if possible although I know there are more recent LXC versions out there. However, if this is a known issue which has been resolved, that would be useful to know.

With thanks in advance,

Adrian

2

LXC itself doesn’t set or even query shmall and shmmax, so changing LXC versions wouldn’t change this behavior.

What you’re seeing is what the kernel is telling you is set. I’m unfortunately not familiar with how those two particular settings are namespaced and interact with things like cgroup memory limits.