[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: LimitRange doesn't apply to swap space - is this the intended behavior?

I did not see in the original question the version of OpenShift that was being exercised, but as of Jun 8, upstream Kubernetes tells docker to disable memory swap for a container when it launches.   So if a limit is specified, the container should not be able to access swap anymore in recent versions.

If a container is still able to access swap, it would be a bug either in upstream Kubernetes or Docker that we would need to track down.

As for allowing swap for other system processes, that won't work when the Kubelet becomes more intelligent in handling available memory on a node versus just its capacity minus scheduled-pods.   The long term plan is to allow a Kubelet to dynamically adjust its reported available memory to the scheduler to handle when system processes consume more memory as load increases.  For example, as more containers are run, docker daemon itself consumes more memory.

On Monday, November 2, 2015, Andy Grimm <agrimm redhat com> wrote:

Why wouldn't you at least set the memsw limit to match the memory limit as a safeguard, though?  There doesn't seem to be any harm it that, even if best practice is to disable it.  Also, you could allow swappiness to be set to zero for the pods to prevent them from swapping but still allow other system processes to do so.

On Nov 2, 2015 4:27 PM, "Derek Carr" <decarr redhat com> wrote:
The intended behavior is to always run with swap disabled on the nodes.

In effect, not disabling swap will prevent us from providing any resource guarantees in the future.

The latest documentation for Origin explains in more detail why this is necessary:

users mailing list
users lists openshift redhat com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]